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NOTE DE L'EDITEUR 
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a un consensus. Ce processus, qui rassemble des participants benevoles, recherche egalement les points de vue de 
personnes interessees par le sujet de cet ouvrage. Si le PMI assure I'administration du processus et fixe les regies qui 
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tester, d’evaluer ou de verifier independamment I’exactitude ou I’exhaustivite des informations presentees, pas plus que 
la solidite des jugements exprimes dans ses publications de normes et de directives. 

Le PMI decline toute responsabilite en cas de dommages corporels, materiels ou autres de quelque nature que ce 
soit, particulars, indirects, accessoires ou compensatoires, resultant de la publication, de I’application ou de la confiance 
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professionnels ou de tout autre type au nom de quelque personne physique ou morale que ce soit, ni pour son compte, 
ni de repondre a un devoir qui incombe a une autre personne physique ou morale au benefice d’un tiers. Toute personne 
utilisant le present ouvrage devrait s'appuyer sur son propre jugement independant ou, lorsque cela s’avere approprie, 
faire appel aux conseils d’un specialiste competent afin de determiner comment exercer une prudence raisonnable en 
toute circonstance. D’autres sources des informations et d’autres normes concernant le sujet couvert par le present 
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Le PMI ne dispose d’aucun pouvoir pour faire respecter la conformite au contenu du present ouvrage, et ne s’engage 
nullement a surveiller ni a faire respecter une telle conformite. Le PMI n'exerce aucune activite de certification, de test 
ni d’inspection de produits, de conception ou d'installation relatifs a la sante ou a la securite des personnes et des biens. 
Toute certification ou autre declaration de conformite avec des informations relatives a la sante ou a la securite des 
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sous I’unique responsabilite de la personne ou de I'organisme qui la certifie ou la declare. 
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Premiere partie 


Guide du 

Corpus des Connaissances 
en Management de Projet 

{GUIDE PMBOK®) 






INTRODUCTION 


1.1 PRESENTATION ET OBJECTIF DE CE GUIDE 

Le management de projet est une discipline pratiquee depuis des siecles. Parmi les exemples de realisations de 
projets figurent: 

♦ les pyramides de Gizeh ; 

♦ les Jeux olympiques; 

♦ la Grande Muraille de Chine; 

♦ le Taj Mahal; 

♦ la publication d’un livre pour enfants ; 

♦ le Canal de Panama; 

♦ le developpement d’avions de ligne a reaction ; 

♦ le developpement du vaccin contre la poliomyelite; 

♦ I’alunissage d’astronautes; 

♦ des logiciels commerciaux; 

♦ des recepteurs GPS ; 

♦ la mise en orbite de la station spatiale internationale (ISS) autour de la Terre. 

Les resultats de ces projets ont ete obtenus par I'application des pratiques, principes, processus, outils et techniques 
du management de projet par les managers et les leaders. Les managers de ces projets ont utilise des competences- 
cles et ont mis en application des connaissances de fagon a satisfaire leurs clients et les autres personnes impliquees 
dans, et affectees par le projet. Au milieu du XXe siecle, les chefs de projet ont commence a vouloir faire reconnaitre le 
management de projet en tant que profession a part entiere. L’un des aspects de cette demarche a consiste a obtenir 
un consensus sur le management de projet, mis sous la forme du corpus des connaissances (body of knowledge, BOK). 
Ce corpus des connaissances est ensuite devenu le corpus des connaissances en management de projet (PMBOK). Par 
la suite, le Project Management Institute (PMI) a cree une reference de base sous forme de tableaux et de glossaires 
pour le PMBOK. Les chefs de projet se sont ensuite rendu compte que le PMBOK ne peut etre contenu dans un seul 
ouvrage. Par consequent, le PMI a redige et publie un Guide du Corpus des connaissances en management de projet 
(Guide PMBOK 0 ). 

Le PMI a defini le corpus des connaissances en management de projet (project management body of knowledge, 
PMBOK) comme un terme decrivant I’ensemble des connaissances du management de projet. Le corpus des 
connaissances en management de projet inclut les pratiques classiques, largement appliquees, ainsi que les nouvelles 
pratiques innovantes en emergence au sein de la profession. 
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Le Corpus des connaissances (body of knowledge, BOK) contient des documents publies ainsi que des documents 
non publies. Ce corpus des connaissances evolue en permanence. Ce Guide PMBOK® designe un sous-ensemble du 
corpus des connaissances en management de projet, generalement reconnu comme etant les bonnes pratiques. 

♦ Generalement reconnu signifie que les connaissances et les pratiques decrites sont applicables la plupart du 
temps a la plupart des projets, et qu’un consensus existe quant a leur valeur et a leur utilite. 

♦ Bonnes pratiques signifie qu’il existe un large consensus sur le fait que I’application de ces connaissances, 
de ces competences, de ces outils et de ces techniques aux processus de management de projet ameliore les 
chances de succes des divers projets en produisant les valeurs et les resultats commerciaux attendus. 

Le chef de projet collabore avec I'equipe projet et les autres parties prenantes afin de determiner et d’utiliser les 
bonnes pratiques generalement reconnues pour chaque projet. La technique determinant la combinaison appropriee 
des processus, des donnees d’entree, des outils, des techniques, des donnees de sortie et des phases du cycle de vie 
en vue de manager un projet est appellee«I’adaptation»de I’application des connaissances decrites dans ce guide. 

Ce Guide PMBOK ® n’est pas une methodologie. Une methodologie est un systeme de pratiques, de techniques, de 
procedures et de regies utilisees par les personnes travaillant dans une discipline. Le Guide PMBOK® est le fondement 
sur lequel les organisations peuvent s'appuyer pour creer les methodologies, les politiques internes, les procedures, 
les regies, les outils, les techniques et les phases de cycle de vie necessaires a la pratique du management de projet. 


1.1.1 LE STANDARD DE MANAGEMENT DE PROJET 

Ce guide s’appuie sur le standard de management de projet « The Standard for Project Management» [1], Un 
standard est un document redige par une autorite, en fonction d’un usage ou d’un consentement general afin de servir 
de modele. Le standard pour le management de projet, approuve par I'American National Standards Institute (ANSI), a 
ete elabore selon un processus consensuel, ouvert, equitable et equilibre. Le standard e st une reference fondamentale 
pour les programmes de developpement professionnel et la pratique de management de projet du PMI. Le standard et 
le guide sont bases sur les pratiques descriptives plutot que sur les pratiques normatives, car le management de projet 
doit etre adapte afin de repondre aux besoins du projet. Ainsi, le standard identifie les processus qui sont considers 
comme de bonnes pratiques, pour la plupart des projets et la plupart du temps. Le standard identifie egalement les 
donnees d’entree et de sortie qui sont generalement associees a ces processus. Le standard ne requiert pas qu’un 
processus ou une pratique particuliere soit applique. Le standard pour le management de projet fa\t partie de la partie 
II du Guide du Corpus des connaissances en management de projet (Guide PMBOK®). 

Le Guide PMBOK® ex plique plus en detail les concepts cles, les tendances emergentes, les considerations pouradapter 
les processus de management de projet et les informations sur I’application des outils et des techniques aux projets. 
Les chefs de projet peuvent utiliser une ou plusieurs methodologies pour appliquer les processus de management de 
projet decrits dans le standard. 
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Cet ouvrage se limite a la discipline du management de projet, et non sur I'eventail complet des portefeuilles, des 
programmes et des projets. Les portefeuilles et les programmes ne seront abordes que dans le cadre de leur interaction 
avec les projets. PMI publie deux autres standards relatifs aux managements de portefeuille et de programme : 

♦ The Standard for Portfolio Management [2]; 

♦ The Standard for Program Management [3]. 

1.1.2 VOCABULAIRE COMMUN 

Un vocabulaire commun est un element essentiel d’une discipline professionnelle. Le lexique du management de 
projet du PMI, intitule PMI® Lexicon of Project Management Terms [4], fournit les elements de base du vocabulaire 
professionnel pouvant etre utilises de fagon coherente par les organisations, par les chefs de projet ou de programme 
ou les responsables de portefeuille, ainsi que par d’autres parties prenantes. Ce lexique continuera a evoluer au fil du 
temps. Le glossaire de ce guide contient le vocabulaire du lexique ainsi que d’autres definitions. Les projets peuvent 
utiliser d’autres termes, specifiques a certaines industries. 


1.1.3 CODE DE DEONTOLOGIE ET DE CONDUITE PROFESSIONNELLE 

En publiant un Code de deontologie etde conduite professionnelle [5], le PMI souhaite inspirer confiance aux metiers 
du management de projet et aider les professionnels a prendre des decisions eclairees, notamment dans des situations 
delicates ou ils peuvent etre amenes a compromettre leur integrity ou leurs valeurs. Les valeurs les plus importantes 
dans la communaute globale du management de projet sont la responsabilite, le respect, I’equite et I’honnetete. Ces 
valeurs constituent le fondement du Code de deontologie etde conduite professionnelle. 

Cet ouvrage est compose de standards revetant un caractere tant ideal qu’obligatoire. Les standards ideaux decrivent 
la conduite que les professionnels, egalement membres du PMI, titulaires d’une certification ou volontaires, s’efforcent 
de maintenir. Bien qu’il soit difficile de mesurer I’adhesion aux standards ideaux, il est attendu que ceux-ci soient 
appliques par les professionnels. Cet aspect est imperatif. Les standards obligatoires etablissent des exigences strictes. 
Dans certains cas, ils limitent ou interdisent le comportement du professionnel. Les professionnels qui sont membres 
du PMI, titulaires d’une certification ou volontaires, et dont le comportement est contraire a ces standards feront I’objet 
de mesures disciplinaires devant le Comite de deontologie du PMI. 
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1.2 ELEMENTS FONDAMENTAUX 


Cette section decrit les elements fondamentaux necessaires pour comprendre et travailler dans le domaine du 
management de projet. 


1.2.1 PROJETS 

Un projet est une initiative temporaire entreprise dans le but de creer un produit, un service ou un resultat unique. 

♦ Un produit, un service ou un resultat unique. Un projet est entrepris afin d’atteindre un objectif grace a la 
realisation de livrables. Un objectif est quelque chose vers lequel un travail devra etre oriente, une position 
strategique ou un but a atteindre, un resultat a obtenir, un produit a fabriquer ou un service a fournir. Un livrable 
est un produit, resultat ou capacite a realiser un service, de caractere unique et verifiable, qui doit etre produit 
pour achever un processus, une phase ou un projet. Les livrables peuvent etre tangibles ou intangibles. 

L'accomplissement des objectifs du projet permet de creer au moins un des livrables suivants : 

■ un produit specifique pouvant etre un composant, une amelioration, la correction d’un element comportant 
un defaut, ou un produit fini; 

■ un service specifique ou la capacite de fournir un service (par exemple, une fonction de support a la production 
ou a la distribution); 

■ un resultat specifique, tel qu’une realisation ou un document (par exemple, un projet de recherche destine a 
identifier une tendance, ou a savoir si un nouveau processus sera utile a la societe); 

■ une combinaison specifique d’un ou de plusieurs produits, services ou resultats (par exemple, une application 
logicielle, la documentation associee et les services d’assistance technique). 

Des activites et livrables du projet peuvent contenir des elements repetitifs. Cette repetition ne change en rien 
les caracteristiques fondamentales et specifiques du travail du projet. Par exemple, des immeubles de bureaux 
peuvent etre construits avec des materiaux identiques ou similaires, et par la meme equipe, ou par differentes 
equipes. Chaque projet d’immeuble demeure neanmoins specifique dans ses principales caracteristiques (par 
exemple, le lieu, la conception, I’environnement, la situation et les personnes concernees). 

Les projets sont entrepris a tous les niveaux organisationnels. Un projet peut impliquer une personne ou un groupe. 
Un projet peut impliquer une ou plusieurs unites organisationnelles appartenant a des organisations multiples. 
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Comme exemples de projets, on peut citer: 

■ la mise au point d’un nouveau compose pharmaceutique pour le marche; 

■ le developpement d’un service de guide touristique; 

■ la fusion de deux organisations; 

■ I'amelioration d’un processus au sein d’une organisation ; 

■ I’acquisition et Installation d’un nouveau materiel informatique dans une organisation ; 

■ I’exploration petroliere dans une region ; 

■ la modification d’un logiciel informatique utilise dans une organisation ; 

■ les travaux de recherches en vue de developper un nouveau precede de fabrication ; 

■ la construction d’un batiment. 

♦ Une initiative temporaire. La nature temporaire des projets implique que le projet a une date de commencement 
et de fin determinees. Elle ne signifie pas pour autant qu’un projet est de courte duree. Le projet prend fin 
lorsqu'au moins un des points suivants se confirme : 

■ Les objectifs du projet ont ete atteints. 

■ Les objectifs ne seront ou ne sont pas realisables. 

■ Les ressources financieres sont epuisees ou ne sont plus disponibles pour le projet. 

■ Le besoin a disparu. (Par exemple, le client ne veut plus du projet, la strategie connart des changements ou 
des priorites met un terme au projet, le management de I’organisation ordonne la fin du projet.) 

■ Les ressources humaines ou materielles ne sont plus disponibles. 

■ Le projet est arrete pour des raisons juridiques ou de commodite. 

Les projets sont temporaires, mais leurs livrables peuvent continuer d’exister apres la fin du projet. Les projets 
peuvent produire des livrables de nature sociale, economique, materielle ou environnementale. Par exemple, le 
projet de construction d’un monument national aboutira a un livrable prevu pour durer des siecles. 
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♦ Les projets induisent le changement. Les projets induisent le changement au sein des organisations. Dans 
une perspective managerial, un projet a pour but de faire passer une organisation d’un etat a un autre afin 
d’atteindre un objectif precis (voir la figure 1-1). Avant le lancement du projet, I'organisation se trouve dans ce 
que Ton appelle couramment I'etat actuel, tandis que I’etat futur est le resultat souhaite du changement induit 
par le projet. 

Pour certains projets, il s'agit de creer un etat de transition dont les diverses etapes constituent un ensemble 
continu jusqu'a I’etat futur. Avec le succes d’un projet, I'organisation passe a I’etat futur et atteint I’objectif precis. 
Pour obtenir plus d’informations sur le changement et le management de projet, consultez Managing Change in 
Organizations: A Practice Guide [6]. 



Figure 1 -1. Transition des etats organisationnels via un projet. 
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♦ Les projets creent de la valeur commerciale. Le PMI definit la valeur commerciale comme le benefice net 
quantifiable emanant d’un effort commercial Ce benefice peut etre tangible ou intangible. Dans la business 
analysis, la valeur commerciale est consideree comme des elements, tels que le temps, I'argent, les biens ou les 
intangibles, fournis en retour d’un echange (voir Business Analysis for Practitioners: A Practice Guide, p. 185 [7]). 

La valeur commerciale d’un projet designe le benefice que les resultats d’un projet specifique conferent a ses 
parties prenantes, sous forme tangible et/ou intangible. 

Parmi les exemples d’elements tangibles, on trouve : 

■ les actifs monetaires ; 

■ la capitalisation boursiere; 

■ les equipements; 

■ les installations; 

■ les outils; 

■ les parts de marche. 

Parmi les exemples d’elements intangibles, on trouve : 

■ la bonne volonte; 

■ la notoriete de la marque; 

■ I’utilite publique; 

■ les marques commerciales; 

■ I'alignement strategique; 

■ la reputation. 

♦ Le contexte du lancement du projet. Les dirigeants lancent des projets en fonction des facteurs qui 
influencent leur organisation. Ces facteurs sont repartis en quatre categories fondamentales qui illustrent le 
contexte d’un projet (voir la figure 1 -2): 

■ respecter les exigences reglementaires, juridiques ou sociales ; 

■ repondre aux demandes ou aux besoins des parties prenantes; 

■ appliquer des strategies commerciales ou technologiques ou changer les mesures existantes ; 

■ creer, ameliorer ou corriger des produits, des processus ou des services. 
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Ces facteurs influencent les operations en cours et les strategies commerciales d’une organisation. Les dirigeants 
doiventtenir compte de ces facteurs afin d'assurer la viabilite de I'organisation. Les projets donnent aux organisations 
les moyens de reussir a apporter les changements necessaires pour faire face a ces facteurs. Enfin, ces facteurs 
devraient etre lies aux objectifs strategies de I'organisation et a la valeur commerciale de chaque projet. 

Le tableau 1-1 montre comment les exemples de facteurs pourraient concorder avec une ou plusieurs categories 
fondamentales de facteurs. 
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Tableau 1-1. Exemples de facteurs de creation d’un projet 


Facteur specifique 

Exemples de facteurs specifiques 

Respecter les exigences 

reglementaires, juridiques 

ou sociales 

Repondre aux demandes ou 

aux besoins des parties prenantes 

Creer, ameliorer ou corriger 

des produits, des processus ou 

des services 

Appliquer des strategies 

commerciales ou technologiques 

ou changer les mesures existantes 

Nouvelle technologie 

Une entreprise d’electronique autorise un nouveau projet a developper 
un ordinateur portable plus rapide, moins cher et plus petit grace 
a des innovations en matiere de memoire et de technologie electronique 



X 

X 

Forces concurrentielles 

Si un concurrent pratique des prix inferieurs, il est necessaire de reduire 
les couts de production pour rester competitif 




X 

Problemes materiels 

Des fissures sur certains contreforts d'un pont municipal sont a I'origine 
d'un projet visant a resoudre les problemes 

X 


X 


Changements politiques 

Un nouvel elu initie des changements dans le financement du projet actuel 




X 

Demande du marche 

Un constructeur automobile autorise, face a une penurie d’essence, le projet 
de construction d’un plus grand nombre de voitures peu gourmandes en carburant 


X 

X 

X 

Changements 

economiques 

Un ralentissement economique change les priorites d’un projet actuel 




X 

Demande client 

Une compagnie d’electricite autorise le projet de construction d’une nouvelle 
sous-station pourdesservir un nouveau pare industriel 


X 

X 


Demandes des parties 
prenantes 

Une partie prenante exige que I’organisation produise une nouvelle donnee 
de sortie 


X 



Exigences juridiques 

Un fabricant de produits chimiques autorise un projet d'elaboration de lignes 
directrices relatives a la bonne manipulation d'un nouveau produit toxique 

X 




Ameliorations des 
processus commerciaux 

Une organisation met en ceuvre un projet resultant d'un exercice de cartographie 
de la chaTne de valeur Lean Six Sigma 



X 


Opportunity strategique 
ou besoin commercial 

Une entreprise de formation autorise le projet de creation d’une nouvelle 
formation pour augmenter ses revenus 



X 

X 

Besoin social 

Une organisation non gouvernementale, dans un pays en voie 
de developpement, autorise un projet fournissant des systemes d'alimentation 
en eau potable, des toilettes publiques et une education sanitaire 
aux communautes affectees par des taux eleves de maladies infectieuses 


X 



Considerations 

environnementales 

Une entreprise publique autorise le projet de creation d'un nouveau service 
de partage de voitures electriques en vue de reduire la pollution 



X 

X 


9 























1.2.2 L’IMPORTANCE DU MANAGEMENT DE PROJET 


Le management de projet est I’application de connaissances, de competences, d’outils et de techniques aux activites 
d’un projet afin d’en satisfaire les exigences. II s’effectue en appliquant et en integrant, de maniere appropriee, les 
processus de management de projet identifies pour le projet. De plus, il permet aux organisations d'executer des projets 
de maniere efficace. 

Un management de projet efficace aide les personnes, les groupes et les organisations publiques et privees a: 

♦ atteindre les objectifs commerciaux definis; 

♦ repondre aux attentes des parties prenantes; 

♦ etre plus previsibles ; 

♦ accroTtre les chances de succes ; 

♦ livrer les bons produits au moment opportun ; 

♦ resoudre les problemes et points a traiter; 

♦ gerer a temps la reponse aux risques ; 

♦ optimiser I’utilisation des ressources organisationnelles ; 

♦ identifier, recuperer ou mettre fin aux projets voues a I’echec; 

♦ gerer les contraintes (par exemple, le perimetre, la qualite, I'echeancier, les couts, les ressources); 

♦ mettre en balance I’influence des contraintes sur le projet (par exemple, une augmentation du perimetre du projet 
peut entrainer une hausse du cout ou une acceleration de I’echeancier); 

♦ mieux gerer les changements. 

Un projet mal gere ou I’absence de management de projet se traduit par: 

♦ des delais non respectes ; 

♦ des depassements de couts; 

♦ une mauvaise qualite; 

♦ une reprise; 

♦ une expansion incontrolee du projet; 

♦ la perte de la reputation de I’organisation ; 

♦ des parties prenantes non satisfaites ; 

♦ I’incapacite a atteindre les objectifs du projet. 

Les projets sont indispensables a la creation de valeur et de benefices pour I’organisation. Dans le monde actuel des 
affaires, les dirigeants doivent etre en mesure de gerer leurs activites avec des budgets plus serres, des delais plus 
courts, des ressources plus limitees et des technologies qui evoluent rapidement. Ce monde dynamique connaft des 
changements acceleres. Pour rester competitives, les organisations adoptent le management de projet afin de creer 
constamment de la valeur commerciale. 
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Un management de projet efficace doit etre considere comme une competence strategique au sein des organisations. 
Ainsi, elles peuvent: 

♦ lier les resultats du projet aux objectifs commerciaux; 

♦ etre plus competitives sur leurs marches; 

♦ perenniser leurs activites ; 

♦ reagir face a I’impact des changements de I’environnement commercial sur les projets en adaptant les plans de 
management de projet (voir la section 4.2). 


1.2.3 RELATIONS ENTRE MANAGEMENT DE PROJET, MANAGEMENT DE PROGRAMME, MANAGEMENT 
DE PORTEFEUILLE ET GESTION DES OPERATIONS 

1.2.3.1 PRESENTATION 

L’usage des processus, outils et techniques du management de projet est une fondation solide permettant aux 
organisations d’atteindre leurs buts et objectifs. Un projet peut etre manage de trois fagons distinctes, a savoir comme un 
projet autonome (en dehors d’un portefeuille ou d’un programme), au sein d’un programme ou au sein d’un portefeuille. 
Dans ces deux derniers cas, les chefs de projet interagissent avec les responsables de portefeuille et les chefs de 
programme. Par exemple, plusieurs projets peuvent etre necessaires pour atteindre les divers buts et objectifs de 
I’organisation. Auquel cas, il peut etre possible de regrouper les projets en un programme. Un programme designe un 
groupe de projets, d’autres programmes et d’activites de programme apparentes dont le management est coordonne 
afin d’obtenir des benefices qui ne seraient pas possibles en les traitant isolement. Les programmes ne sont pas des 
projets de grande envergure. Un grand projet reste un projet. A titre d’indication, un grand projet coute au minimum 
1 milliard de dollars americains, implique au moins 1 million de personnes et s’etale sur plusieurs annees. 

Les organisations peuvent choisir d’utiliser un portefeuille de projets afin de manager efficacement plusieurs 
programmes et projets en cours. Un portefeuille designe des projets, des programmes, des portefeuilles secondaires 
et des operations, manages en tant que groupe, afin d’atteindre des objectifs strategies. La figure 1-3 montre un 
exemple de la relation entre les portefeuilles, les programmes, les projets et les operations dans une situation precise. 

Le management de programme et de portefeuille se difference du management de projet par leurs cycles de vie, 
activites, objectifs, orientation et benefices. Portefeuilles, programmes, projets et operations ont souvent en commun 
les memes parties prenantes et les memes ressources (voir la figure 1 -3), ce qui peut entraTner des conflits au sein de 
I’organisation. Ce genre de situation cree le besoin de coordination via I’utilisation des managements de portefeuille, de 
programme et de projet afin de parvenir a un equilibre viable. 


11 



La figure 1-3 illustre la structure d’un portefeuille indiquant les relations entre les programmes, les projets, les 
ressources partagees et les parties prenantes. Les composants du portefeuille sont regroupes afin de faciliter la 
gestion du travail et la gouvernance de fagon a atteindre les objectifs strategiques et les priorites de I'organisation La 
planification du portefeuille et de I’organisation influence les composants du portefeuille selon une priorite basee sur 
le risque et le financement entre autres considerations. La vision au travers du portefeuille permet aux organisations 
de voir comment le portefeuille ref I ete les buts strategiques. Elle permet egalement d’appliquer et de coordonner la 
gouvernance des portefeuille, programme et projet. Cette gouvernance coordonnee permet d’affecter les ressources 
humaines, financieres ou materielles sur la base des performances et des benefices attendus. 


Strategic organisationnelle 


* 

Exemple de portefeuille 


Programme 


Programme 


Portefeuille 

A 


B 


A 


Programme 

81 


Programme 

C 


Projet 

Projet 

Projet 

Projet 

Projet 

Projet 

Projet 

Projet 

Projet 

Operations 

1 

2 

3 

4 

5 

6 

7 

8 

9 


Ressources partagees et parties prenantes 


Figure 1 -3. Portefeuilles, programmes, projets et operations 


En observant le management de projet, programme et portefeuille du point de vue de I’organisation, on note que: 

♦ le management de projet et de programme se concentre sur«bien faire le programme/projet»; 

♦ le management de portefeuille se concentre sur«faire le bon programme/projet». 

Le tableau 1-2 donne une vue d’ensemble comparative des portefeuilles, des programmes et des projets. 
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Tableau 1-2. Apergu comparatif du management de projet, de programme et de portefeuille 


Management de projet organisationnel 



Projets 

Programmes 

Portefeuilles 

Definition 

Un projet est une initiative temporaire 
entreprise dans le but de creer 
un produit, un service ou un resultat 
unique. 

Un programme designe un groupe 
de projets, de programmes 
secondaires et d’activites 
de programme apparentes dont 
le management est coordonne afin 
d'obtenir des benefices qui 
ne seraient pas possibles en 
les traitant isolement. 

Un portefeuille designe des projets, 
des programmes, des portefeuilles 
secondaires et des operations, 
manages en tant que groupe, afin 
d’atteindre des objectifs strategiques. 

Perimetre 

Les projets ont des objectifs definis. 

Le perimetre est progressivement 
etabli tout au long du cycle de vie 
du projet. 

Les programmes ont un perimetre 
qui englobe les perimetres de leurs 
composants. Les programmes 
apportent des benefices a une 
organisation en faisant en sorte que 
les donnees de sortie et les resultats 
de leurs composants soientfournis 
de maniere coordonnee et 
complementaire. 

Les portefeuilles ont un perimetre 
organisationnel qui evolue avec 
les objectifs strategiques 
de ^organisation. 

Changement 

Les chefs de projet s’attendent a ce 
qu'il y ait des changements et 
mettent en oeuvre des processus 
destines a les maTtriser. 

Les programmes sont manages de 
sorte a accepter le changement et 
a s'y adapter dans la mesure ou il est 
necessaire pour optimiser 
la fourniture de benefices au fur 
et a mesure que les composants 
des programmes donnent 
des resultats et/ou des donnees 
de sortie. 

Les chefs de portefeuille suivent 
les changements en permanence 
dans des environnements internes 
et externes plus larges. 

Planification 

Les chefs de projet developpent 
progressivement des informations 
de haut niveau dans le cadre 
de plans detailles tout au long 
du cycle de vie du projet. 

Les programmes sont manages 
a I’aide de plans de haut niveau qui 
suivent les interdependences et 
les progres de leurs composants. 

Des plans de programme sont 
egalement utilises pour orienter 
la planification au niveau 
du composant. 

Les chefs de portefeuille creent et 
assurent le bon fonctionnement 
des processus necessaires et de 
la communication relative 
au portefeuille dans son ensemble. 

Management 

Les chefs de projet managent I’equipe 
projet en vue d’atteindre les objectifs 
de projet. 

Les programmes sont manages par 
les chefs de programme qui veillent 
a ce que les benefices du programme 
soient fournis comme prevu, 
en coordonnant les activites 
des composants de ces programmes. 

Les chefs de portefeuille peuvent 
manager et coordonner I'equipe 
de management de portefeuille, 
ou I’equipe programme et projet qui 
peut etre chargee d’elaborer 
des rapports dans le cadre 
du portefeuille global. 

Suivi 

Les chefs de projet maltrisent 
le travail de production des produits, 
services ou resultats pour lequel 
le projet a ete entrepris. 

Les chefs de programme suivent 
revolution des composants 
du programme en vue de garantir 
le respect des objectifs generaux, 
des echeanciers, du budget et 
des benefices du programme. 

Les chefs de portefeuille suivent 
les changements strategiques 
et regroupent I'affectation 
des ressources, les resultats 
en termes de performance et 
le risque du portefeuille. 

Reussite 

La reussite est mesuree par produit 
et en fonction de la qualite du projet, 
du respect des delais, du respect 
du budget et du degre de satisfaction 
du client. 

La reussite d'un programme est 
mesuree selon sa capacite a fournir 
les benefices attendus a 
une organisation, ainsi que son 
efficacite et son efficience dans 
la fourniture de ces benefices. 

La reussite est mesuree en termes 
de rendement global des 
investissements et de realisation 
des benefices du portefeuille. 

> 
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1.2.3.2 MANAGEMENT DE PROGRAMME 


Le management de programme est defini comme I'application de connaissances, de competences et de principes a 
un programme, afin d’atteindre les objectifs du programme et de parvenir a des benefices et une maitrise qui seraient 
inaccessibles en gerant les composants du programme individuellement. Un composant d’un programme designe 
les projets et les autres programmes contenus dans le programme. Le management de projet porte une attention 
particuliere aux interdependances au niveau du projet afin de determiner I’approche optimale pour manager le projet. 
Le management de programme se concentre sur les interdependances entre les projets eux-memes ainsi qu’entre les 
projets et le programme, ceci afin de determiner I'approche optimale pour gerer ces interdependances. Les actions liees 
a ces interdependances entre le programme et les projets peuvent comprendre : 

♦ I'alignement sur la direction organisationnelle ou strategique qui affecte les objectifs et les buts du programme 
et des projets; 

♦ I’attribution du perimetre du programme aux composants du programme; 

♦ la gestion optimale des interdependances entre les composants du programme ; 

♦ la gestion des risques du programme susceptibles d’avoir une incidence sur plusieurs projets du programme; 

♦ la resolution des contraintes et des conflits qui affectent plusieurs projets du programme ; 

♦ la resolution des points a traiter entre les composants du programme et le programme lui-meme; 

♦ la gestion des demandes de changement dans un cadre de gouvernance partagee; 

♦ I’affectation de budgets a plusieurs projets du programme; 

♦ la garantie de la realisation des benefices du programme et des composants du projet. 

Un exemple de programme est celui d’un nouveau systeme de satellite de telecommunication comprenant des projets 
de conception du satellite et des stations au sol, leur construction, le lancement du satellite et I’integration du systeme. 

Pour obtenir plus d’informations sur le management de programme, consultez le standard de management de 
programme «The Standard for Program Management [3] ». 
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1.2.3.3 MANAGEMENT DE PORTEFEUILLE 


Un portefeuille designe des projets, des programmes, des portefeuilles secondaires et des operations, manages en 
tant que groupe, afin d’atteindre des objectifs strategies. 

Le management de portefeuille est defini comme le management centralise d’un ou de plusieurs portefeuilles afin 
d’atteindre des objectifs strategies. Les projets ou les programmes du portefeuille ne sont pas necessairement 
interdependants ou directement lies. 

Le management de portefeuille vise a: 

♦ orienter les decisions d'investissement de I’organisation ; 

♦ choisir la combinaison optimale de programmes et de projets pour atteindre les objectifs strategies; 

♦ assurer la transparence des decisions ; 

♦ definir la priorite d’affectation des equipes et des ressources materielles ; 

♦ accroTtre la probability de realiser le retour sur investissement souhaite; 

♦ centraliser la gestion du profil de risque consolide de tous les composants. 

Le management de portefeuille permet egalement de confirmer que le portefeuille est coherent et aligne sur les 
strategies de I’organisation. 

La maximisation de la valeur du portefeuille suppose un examen minutieux des composants qu’il contient. Ces 
derniers sont classes par ordre de priorite. Ainsi, ceux qui contribuent le plus aux objectifs strategies de I’organisation 
disposent des ressources financiers, humaines et materielles. 

Par exemple, une organisation d'infrastructure dont I'objectif strategique est de maximiser le rendement de son 
capital investi peut vouloir constituer un portefeuille comprenant des projets petroliers et gaziers, de production 
d’energie, d’adduction d’eau, de routes, de voies ferrees et d’installations aeroportuaires. L’organisation peut choisir, 
dans ce groupement, des projets apparentes et decider de les organiser en un portefeuille. Tous les projets de 
production d’energie peuvent etre regroupes en un portefeuille de production d’energie. De la meme fagon, tous les 
projets d’adduction d’eau peuvent etre regroupes en un portefeuille d’adduction d’eau. Toutefois, lorsque I’organisation 
a des projets de conception et de construction d’une centrale electrique, puis exploite cette centrale pour produire de 
I’energie, ces projets lies peuvent etre regroupes en un programme. Ainsi, le programme de production d’energie et le 
programme d’adduction d’eau deviennent des composants qui font partie integrate du portefeuille de I’organisation 
d’infrastructure. 

Pour obtenir plus d'informations sur le management de portefeuille, consultez le standard de management de 
portefeuille «The Standard for Portfolio Management [2 ]». 
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1.2.3.4 GESTION DES OPERATIONS 


La gestion des operations est un domaine qui se situe en dehors du perimetre du management de projet formel tel 
que decrit dans ce guide. 

La gestion des operations porte sur la production en continu de biens ou de services. Elle s'assure que les operations 
commerciales se poursuivent efficacement en utilisant un niveau de ressources optimal necessaire pour repondre aux 
exigences des clients. II se rapporte a la gestion des processus qui transforment les donnees d’entree (par exemple, 
les materiaux, les composants, I’energie et la main d’oeuvre) en donnees de sortie (par exemple, les produits, les 
marchandises ou les services). 

1.2.3.5 GESTION DES OPERATIONS ET MANAGEMENT DE PROJET 

Des changements des operations de I’organisation peuvent faire I’objet d’un projet, en particulier, s’il y a des 
changements importants au niveau des operations dus a I’introduction d’un nouveau produit ou d’un nouveau service. 
Les operations courantes se situent en dehors du perimetre d’un projet; toutefois, il existe des points d’intersection la 
ou deux domaines se croisent. 

Au cours du cycle de vie du produit, les projets et les operations peuvent se croiser en certains points, comme : 

♦ lors du developpement d’un nouveau produit, de I'amelioration d’un produit ou de I'extension du perimetre 
operationnel; 

♦ lors de I’amelioration des operations ou du processus de developpement de produit; 

♦ a la fin du cycle de vie du produit; 

♦ a chaque phase de cloture. 

A chacun de ces points, les livrables et les connaissances sont transfers du projet aux operations. Cette application se 
produit par un transfert des connaissances ou des ressources du projet aux operations ou par le transfert de ressources 
operationnelles au projet. 

1.2.3.6 MANAGEMENT DE PROJET ORGANISATIONNEL (ORGANIZATIONAL PROJECT MANAGEMENT OU OPM) 
ET STRATEGIES 

Les portefeuilles, les programmes et les projets sont alignes sur les strategies organisationnelles ou motives par 
elles. Ms different dans leur contribution a la realisation des objectifs strategies. 

♦ Le management de portefeuille s’aligne sur les strategies organisationnelles a travers la selection des programmes 
ou des projets appropries, la priorisation du travail et la mise a disposition des ressources necessaires. 

♦ Le management de programme harmonise les composants de ses programmes et maitrise les interdependences 
pour produire des benefices specifies. 

♦ Le management de projet permet d’atteindre les buts et objectifs de I'organisation. 
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Au sein des programmes ou des portefeuilles, les projets sont un moyen d’atteindre des buts et des objectifs 
organisationnels. Ce qui arrive souvent dans le contexte d’un plan strategique qui est le premier facteur guidant 
les investissements au niveau des projets. L’alignement sur les buts strategies de I’organisation s'obtient par le 
management de portefeuille, de programme et de projet de maniere systematique grace a I’application du management 
de projet organisationnel (Organizational Project Management ou 0PM). Le management de projet organisationnel est 
defini comme un cadre ou le management de portefeuille, de programme et de projet est integre aux procedures 
organisationnelles en vue d’atteindre les objectifs strategies. 

Le butetantdes'assurerquel’organisation execute les bons projets etaffectecorrectement les ressourcesindispensables. 
Le management de projet organisationnel aide egalement a garantir que tous les niveaux de I’organisation comprennent 
la vision strategique, les demarches associees, les objectifs et les livrables. La figure 1-4 montre I’environnement 
organisationnel dans lequel interagissent strategic, portefeuille, programmes, projets et operations. 

Pour plus d’informations sur le management de projet organisationnel, consultez le document Implementing 
Organizational Project Management: A Practice Guide [8]. 



1.2.4 COMPOSANTS DU GUIDE 

Les projets contiennent plusieurs composants principaux qui, lorsqu’ils sont geres efficacement, contribuent a 
leur bonne realisation. Ce guide identifie et explique ces composants. Durant le management d’un projet, les divers 
composants interagissent entre eux. 

Le tableau 1-3 decrit brievement les principaux composants du management de projet. Ces composants sont 
expliques plus en detail dans les paragraphes qui suivent le tableau. 
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Tableau 1-3. Description des principaux composants du Guide PMBOK @ 


Description des principaux 
composants du Guide PMBOK' 

Breve description 

Cycle de vie du projet (section 1.2.4.1) 

Serie de phases du projet, depuis son demarrage jusqu’a sa terminaison. 

Phase du projet (section 1.2.4.2) 

Ensemble d’activites conjointes du projet qui aboutit a la finalisation d’un ou 
de plusieurs livrables. 

Porte de phase (section 1.2.4.3) 

Revue en fin de phase au cours de laquelle la decision est prise de passer a la phase 
suivante, de continuer en apportant des changements ou de mettre fin a 
un programme ou a un projet. 

Processus de management de projet 
(section 1.2.4.4) 

Serie systematique d’activites destinees a produire un resultat final en transformant 
une ou plusieurs donnees d’entree en une ou plusieurs donnees de sortie. 

Groupe de processus de management 
de projet (section 1.2.4.5) 

Groupement logique des donnees d’entree, des outils et techniques, et des donnees 
de sortie du management de projet. Les groupes de processus de management 
de projet comprennent les processus d’initialisation, de planification, d’execution, 
de maTtrise, et enfin de cloture. Les groupes de processus de management du projet 
ne sont pas des phases du projet. 

Domalne de connaissance en management 
de projet (section 1.2.4.6) 

Domaine identifie du management de projet, defini par ses exigences en matiere 
de connaissance et dont le contenu est decrit en termes de ses processus, 
ses pratiques, ses donnees d'entree et de sortie, ses outils et techniques. 


Cycle de vie du projet 



Groupes de processus 



10 Domaines de connaissance 


CODE: 


0 Porte I I Phase I Utilisation 

de phase |_| du projet | potentielle 


Echeance 


Figure 1-5. Interrelation des principaux composants du Guide PMBOK® dans les projets. 
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1.2.4.1 CYCLES DE VIE DU PROJET ET DU DEVELOPPEMENT 


Le cycle de vie d’un projet est la serie de phases que celui-ci traverse, depuis son lancement jusqu’a sa cloture. II 
fournit un cadre de reference pour manager le projet, quelle que soit la nature du projet concerne. Les phases sont 
effectuees de fagon sequentielle, iterative ou en parallele. Le cycle de vie generique illustree a la figure 1 -5 s'applique 
a tous les projets. 

Les cycles de vie du projet peuvent etre predictifs ou adaptatifs. En regie generate, le cycle de vie du projet comporte 
une ou plusieurs phases qui sont associees au developpement du produit, du service ou du resultat. Ces phases 
composent le cycle de developpement, qui peut etre predictif, iteratif, incremental, adaptatif ou hybride. 

♦ Dans un cycle de vie predictif, le perimetre, la duree et les couts du projet sont determines au cours des premieres 
phases du cycle de vie. Les changements apportes au perimetre du projet doivent etre rigoureusement geres. Les 
cycles de vie predictifs peuvent aussi etre appeles cycles de vie type waterfall. 

♦ Dans le cas d'un cycle de vie iteratif, le perimetre du projet est generalement determine au debut de son cycle de 
vie. Les estimations des delate et des couts sont changees regulierement a mesure que I’equipe projet comprend 
mieux le produit. Les iterations developpent le produit a travers une serie de cycles repetitifs, tandis que les 
increments ajoutent progressivement des fonctionnalites au produit. 

♦ Danslecasd’uncycledevie incrementiel,leslivrablesproviennentd’uneseried’iterationsquiajoutentprogressivement 
des fonctionnalites dans une periode de temps predetermines. Les livrables incluent les fonctionnalites necessaires 
et suffisantes pour etre considers comme exhaustifs uniquement apres Iteration finale. 

♦ Les cycles de vie adaptatifs sont agiles, iteratifs ou incrementiels. Le perimetre detaille est defini et approuve avant 
le debut d’une iteration. Les cycles de vie adaptatifs sont aussi appeles cycles de vie bases sur le changement 
ou sur les methodes agiles (voir I’annexe X3). 

♦ Un cycle de vie hybride est une combinaison des cycles de vie predictif et adaptatif. Les elements du projet bien 
connus ou dotes d’exigences etablies suivent un cycle de developpement predictif, tandis que les elements qui 
continuent d’evoluer suivent un cycle de developpement adaptatif. 

II appartient a I’equipe de management de projet de determiner le meilleur cycle de vie pour chaque projet. Le 
cycle de vie du projet doit etre suffisamment flexible pour traiter les divers facteurs du projet. Cette flexibility peut 
etre acquise en : 

♦ identifiant le ou les processus a realiser pour chacune des phases ; 

♦ realisant le ou les processus identifies dans la phase correspondante; 

♦ adaptant les divers attributs d’une phase (par exemple, le nom, la duree, les criteres de sortie et les criteres d’entree). 

Le cycle de vie du projet est distinct du cycle de vie du produit (qui peut etre developpe par un projet). Le cycle 
de vie du produit est une serie de phases qui represented revolution d’un produit, du concept, en passant par la 
livraison, la croissance et la maturity jusqu'a son retrait du marche. 
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1.2.4.2 PHASE DU PROJET 


Une phase de projet est un ensemble d’activites du projet liees logiquement qui aboutit a I'achevement d’un ou de 
plusieurs livrables. Les phases d’un cycle de vie peuvent etre decrites par divers attributs. Les attributs sont mesurables 
et propres a une phase en particulier. Ms comprennent, entre autres : 

♦ le nom (par exemple, Phase A, Phase B, Phasel, Phase 2, phase de proposition); 

♦ le nombre (par exemple, trois phases dans le projet, cinq phases dans le projet); 

♦ la duree (par exemple, 1 semaine, 1 mois, 1 trimestre); 

♦ les besoins en ressources (par exemple, les personnes, les batiments, les equipements); 

♦ les criteres d’entree dans une phase du projet (par exemple, les approbations specifiques documentees, les 
documents specifiques completes); 

♦ les criteres de sortie d’une phase du projet (par exemple, les approbations documentees, les documents 
completes, les livrables acheves). 

Les projets peuvent etre divises en phases distinctes ou en sous-composants. En regie generate, ces phases ou ces 
sous-composants ont des noms qui indiquent le type de travail effectue lors de cette phase. Comme exemples de noms 
de phase, on peut citer: 

♦ le developpement du concept; 

♦ I’etude de faisabilite ; 

♦ les exigences du client; 

♦ le developpement de solutions ; 

♦ la conception; 

♦ le prototypage; 

♦ la construction; 

♦ les tests; 

♦ la transition; 

♦ la mise en service ; 

♦ la revue des jalons ; 

♦ les retours d’experience. 
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Les phases du projet peuvent etre etablies sur la base de facteurs comme: 

♦ les besoins du management; 

♦ la nature du projet; 

♦ les caracteristiques uniques de I’organisation, du secteur d’activite ou de la technologie; 

♦ les elements du projet, notamment, les technologies, I’ingenierie, les affaires, les processus ou les services juridiques; 

♦ les points de decision, comme le financement, l’acceptation/le rejet du projet et la revue des jalons. 

L’utilisation de plusieurs phases permet d’obtenir un meilleur apergu pour manager le projet. De plus, elles offrent la 
possibility d’evaluer les performances du projet et de conduire des actions correctives ou preventives lors des phases 
suivantes. La revue de phase est un composant essentiel utilise avec les phases du projet (voir la section 1.2.4.3). 

1.2.4.3 PORTE DE PHASE 

La porte de phase intervient a la fin d’une phase. Les performances et I’avancement du projet sont compares aux 
documents business et de projet, notamment: 

♦ le business case du projet (voir la section 1.2.6.1); 

♦ la charte du projet (voir la section 4.1); 

♦ le plan de management du projet (voir la section 4.2); 

♦ le plan de gestion des benefices (voir la section 1.2.6.2). 

Suite a cette comparaison, une decision (par exemple, acceptation ou rejet) est prise pour: 

♦ passer a la phase suivante; 

♦ passer a la phase suivante avec un changement; 

♦ terminer le projet; 

♦ rester dans la phase; 

♦ reprendre la phase ou ses elements. 

En fonction de I'organisation, du secteur d’activite ou du type de travail, les sorties de phase peuvent etre appelees 
phase gate, revue de phase, porte d’etape, ou encore point d’arret. Les organisations peuvent utiliser ces revues pour 
examiner d'autres elements pertinents qui depassent le propos de ce guide, comme les modeles ou les documents lies 
au produit. 
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1.2.4.4 PROCESSUS DE MANAGEMENT DE PROJET 


Le cycle de vie du projet est gere en realisant une serie d’activites de management de projet appelees processus 
de management de projet. Chaque processus de management de projet produit une ou plusieurs donnees de sortie a 
partir d’une ou plusieurs donnees d’entree a I'aide des outils et techniques appropries du management de projet. Les 
donnees de sortie peuvent etre des livrables ou des realisations. Ces dernieres sont le resultat final d’un processus. Les 
processus de management de projet s’appliquent universellement quelle que soit I’industrie. 

Ms sont logiquement lies par les donnees de sortie qu’ils produisent. Les processus peuvent contenir, tout au long du 
projet, des activites qui se chevauchent. Les donnees de sortie d’un processus sont en general: 

♦ des donnees d’entree d’un autre processus ; 

♦ des livrables du projet ou d’une phase de projet. 

La figure 1 -6 illustre les relations entre les donnees d’entree, les outils, les techniques et les donnees de sortie dans 
un processus et avec d’autres processus. 




T Outils et techniques^ 




.1 Donnee d'entree H 

.2 Donnee d'entree J 
^- 

.1 TechniqueA 

.2 Outil C 

-/ 

.1 Donnee de sortie du projet A 
.2 Donnee de sortie du projet B 
V__ ) 




Figure 1-6. Exemple de processus: donnees d’entree, outils et techniques et donnees de sortie. 


Le nombre d’iterations des processus et d’iterations entre les processus varie en fonction des besoins du projet. 
De maniere generate, les processus font partie de I’une de trois categories suivantes. 

♦ Processus utilises une fois ou a des moments predefinis du projet. Par exemple, il s’agit des processus 
Elaborer la charte du projet et Clore le projet ou la phase. 

♦ Processus executes periodiquement. Le processus Obtenir les ressources est execute lorsque des ressources 
sont necessaires. Le processus Proceder auxapprovisionnementsMervient avant que Particle fourni soit necessaire. 

♦ Processus realises en continu tout au long du projet. Le processus Definir les activites peut etre realise 
tout au long du cycle de vie du projet, en particulier si le projet a recours a la planification en vagues ou a une 
approche de developpement adaptative. La plupart des processus de maTtrise sont executes du debut a la fin 
du projet. 

Le management de projet est effectue en appliquant et en integrant, de maniere appropriee, des processus de 
management de projet groupes de maniere logique. Bien qu'il existe differentes fagons de regrouper les processus, le 
Guide PMBOK® les rassemble en cinq categories appelees groupes de processus. 
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1.2.4.5 GROUPES DE PROCESSUS DE MANAGEMENT DE PROJET 


Un groupe de processus de management de projet est un regroupement logique des processus de management de 
projet visant a atteindre des objectifs specifiques du projet. Les groupes de processus sont independants des phases du 
projet. Les processus de management de projet sont repartis dans les cinq groupes suivants. 

♦ Groupe de processus d’initialisation. Ces processus permettent de definir un nouveau projet, ou une nouvelle 
phase d’un projet existant, par I’obtention de I’autorisation de demarrer ce nouveau projet ou cette nouvelle phase. 

♦ Groupe de processus de planification. Ces processus permettent de definir le perimetre du projet, d’affiner les 
objectifs et de decider des actions necessaires a I’atteinte des objectifs pour lesquels le projet a ete entrepris. 

♦ Groupe de processus d’execution. Ces processus permettant d’accomplir le travail defini dans le plan de 
management du projet afin de satisfaire aux exigences du projet. 

♦ Groupe de processus de maitrise. Ces processus permettent de suivre, de passer en revue et de reguler 
I'avancement et la performance du projet, d’identifier les endroits ou des changements du plan s'avereraient 
necessaires, et d’entreprendre les changements correspondants. 

♦ Groupe de processus de cloture. Ces processus permettent de realiser ou de clore formellement un projet, une 
phase ou un contrat. 

Le present guide utilise des diagrammes de flux des processus. Les processus de management de projet 
sont lies par des donnees d’entree et de sortie specifiques ; c’est-a-dire que le resultat ou I’aboutissement d’un 
processus peut devenir une donnee d’entree d’un autre processus, sans que ce processus soit necessairement 
dans le meme groupe de processus. II convient de distinguer les groupes de processus des phases de projet (voir 
la section 1.2.4.2). 

1.2.4.6 DOMAINES DE CONNAISSANCE EN MANAGEMENT DE PROJET 

Les processus sont non seulement rassembles en groupes mais aussi classes par domaines de connaissance. Un 
domaine de connaissance est un domaine identifie du management de projet, defini par ses exigences en matiere de 
connaissance et dont le contenu est decrit en termes de ses processus, ses pratiques, ses donnees d’entree et de sortie, 
sesoutils et techniques. 

Si les domaines de connaissance sont etroitement lies, ils sont definis independamment du point de vue du 
management de projet. Les dix domaines de connaissance identifies dans ce guide sont utilises, la plupart du temps, 
dans la majorite des projets. Ces dix domaines de connaissance sont les suivants. 

♦ Gestion de (’integration du projet. Processus et activites qui identifient, definissent, combinent, unifient 
et coordonnent les differents processus et activites de management de projet au sein des groupes de 
processus de management du projet. 

♦ Gestion du perimetre du projet. Processus permettant d’assurer que tout le travail requis par le projet, et 
seulement le travail requis, est effectue pour mener le projet a son terme avec succes. 
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♦ Gestion de Pecheancier du projet. Processus permettant de gerer I’achevement du projet dans les delais impartis. 

♦ Gestion des couts du projet. Processus relatifs a la planification, a I’estimation, a I’etablissement du budget, au 
financement, au provisionnement, a la gestion et a la maTtrise des couts, afin que le projet soit acheve dans les 
limites du budget approuve. 

♦ Gestion de la qualite du projet. Processus de prise en compte de la politique qualite de I’organisation en ce 
qui concerne la planification, la gestion et la maTtrise des exigences de qualite du produit et du projet afin de 
satisfaire aux attentes des parties prenantes. 

♦ Gestion des ressources du projet. Processus qui consistent a identifier, obtenir et gerer les ressources requises 
pour garantir I'achevement du projet avec succes. 

♦ Gestion des communications du projet. Processus requis pour assurer, de maniere appropriee et en temps 
utile, la planification, le recueil, la creation, la distribution, le stockage, la recuperation, la gestion, la maTtrise et 
I’archivage final des informations du projet. 

♦ Gestion des risques du projet. Processus de planification de la gestion des risques, d’identification, d’analyse, 
de planification des reponses, d’execution d’une reponse et de maTtrise des risques d’un projet. 

♦ Gestion des approvisionnements du projet. Processus d’achat ou d’obtention des produits, des services ou 
des resultats necessaires et externes a I’equipe projet. 

♦ Gestion des parties prenantes du projet. Processus requis pour identifier les personnes, les groupes ou les 
organisations susceptibles d’affecter ou d’etre affectes par le projet, pour analyser les attentes des parties 
prenantes et leur impact sur le projet, mais aussi pour developper des strategies de gestion appropriees pour 
mobiliser efficacement les parties prenantes en les impliquant dans les decisions du projet et son execution. 

En fonction de ses besoins, un projet peut necessiter un ou plusieurs autres domaines de connaissance. Par exemple, 
la construction peut solliciter une gestion financiere ou une gestion de la sante et de la securite. Le tableau 1-4 
cartographie les groupes de processus de management de projet et les domaines de connaissance. Ces dix domaines 
de connaissance sont traites plus en detail dans les chapitres 4 a 13. Le tableau donne un apergu des processus de 
base decrits dans les chapitres 4 a 13. 
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Tableau 1-4. Correspondance entre les groupes de processus de management de projet et les domaines de connaissance 


r 


Groupes de processus de management de projet 


Domaines 

de connaissance 

Groupe 
de processus 
d’initialisation 

Groupe 
de processus 
de planification 

Groupe 
de processus 
d'execution 

Groupe 
de processus 
de maTtrise 

Groupe 
de processus 
de cloture 

4. Gestion 

de {’integration 
du projet 

4.1 Elaborer 
la charte du projet 

4.2 Elaborer le plan 
de management 
du projet 

4.3 Diriger et gerer 
le travail du projet 

4.4 Gerer 

les connaissances 
du projet 

4.5 MaTtriser 
le projet 

4.6 MaTtriser 
les changements 

4.7 Clore le projet 
ou la phase 

5. Gestion 
du perimetre 
du projet 


5.1 Planifier 
la gestion 

du perimetre et 
du contenu 

5.2 Recueillir 
les exigences 

5.3 Definir 
le perimetre 

5.4 Creer le WBS 


5.5 Valider 
le perimetre 

5.6 MaTtriser 
le perimetre et 
le contenu 


6. Gestion 

de I’echeancier 
du projet 


6.1 Planifier 
la gestion 

de I’echeancier 

6.2 Definir 
les activites 

6.3 Organiser 
les activites 
en sequence 

6.4 Estimer 
la duree 
des activites 

6.5 Elaborer 
I’echeancier 


6.6 MaTtriser 
I’echeancier 


7. Gestion 
des couts 
du projet 


7.1 Planifier 
la gestion 
des couts 

7.2 Estimer 
les couts 

7.3 Determiner 
le budget 


7.4 MaTtriser 
les couts 


S. Gestion 
de la qualite 
du projet 


8.1 Planifier 
la gestion 
de la qualite 

8.2 Gerer la qualite 

8.3 MaTtriser 
la qualite 


9. Gestion 

des ressources 
du projet 


9.1 Planifier 
la gestion 

des ressources 

9.2 Estimer 
les ressources 
necessaires 
aux activites 

9.3 Obtenir 
les ressources 

9.4 Developper 
I’equipe 

9.5 Gerer I’equipe 

9.6 MaTtriser 
les ressources 


10. Gestion des 
communications 
du projet 


10.1 Planifier 
la gestion des 
communications 

10.2 Gerer les 
communications 

10.3 MaTtriser les 
communications 


11. Gestion 
des risques 
du projet 


11.1 Planifier 
la gestion 
des risques 

11.2 Identifier 
les risques 

11.3 Mettre en 
ceuvre I’analyse 
qualitative 

des risques 

11.4 Mettre en 
ceuvre I’analyse 
quantitative 
des risques 

11.5 Planifier 
les reponses aux 
risques 

11.6 Appliquer 
les reponses 
aux risques 

11.7 MaTtriser 
les risques 


12. Gestion des 
approvision- 
nements 
du projet 


12.1 Planifier 
la gestion 
des approvision- 
nements 

12.2 Proceder 
aux approvision- 
nements 

12.3 MaTtriser 
les approvision 
-nements 


13. Gestion 
des parties 
prenantes 
du projet 

13.1 Identifier les 
parties prenantes 

13.2 Planifier 
I'engagement des 
parties prenantes 

13.3 Gerer 
I’engagement des 
parties prenantes 

13.4 MaTtriser 
I’engagement des 
parties prenantes 
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1.2.4.7 DONNEES ET INFORMATIONS DU MANAGEMENT DE PROJET 


Au cours du cycle de vie d’un projet, un volume significatif de donnees est recueilli, analyse et transforme. Les 
donnees du projet sont recueillies a Tissue des processus et sont partagees au sein de Tequipe projet. Les donnees 
recueillies sont analysees dans le contexte, puis regroupees et transformees pour devenir des informations du projet 
au cours des processus. L’information peut alors etre communiquee verbalement, ou stockee et distribute sous 
forme de rapports de differents formats. Lisez la section 4.3 pour en savoir plus a ce sujet. 

Les donnees de projet sont regulierement recueillies et analysees tout au long du cycle de vie du projet. Les 
definitions suivantes identifient la terminologie relative aux donnees et aux informations du projet. 

♦ Donnees de performance d’execution du travail. Observations brutes et mesures relevees au cours de 
Texecution des activites realisees pour accomplir le travail du projet. Comme exemples, on peut citer le rapport 
du pourcentage d’avancement des travaux effectivement realises, les mesures de qualite et de performance 
technique, les dates de debut et de fin des activites de Techeancier, le nombre de demandes de changement, le 
nombre de defauts, les couts reels et les durees reelles. En regie generate, les donnees du projet sont consignees 
dans le systeme d’information de gestion du projet (Project Management Information System, PMIS) (voir la 
section 4.3.2.2) et les documents de projet. 

♦ Information sur la performance d’execution. Donnees de performance recueillies a travers les divers processus 
de maTtrise qui sont analysees dans leur contexte et integrees sur la base des dependances entre les domaines. 
Elies comprennent I’etat des livrables, I’etat de Tapplication des demandes de changement et les couts estimes 
pour achievement. 

♦ Rapports sur la performance d’execution du travail. Representation physique ou electronique des 
informations sur la performance d’execution du travail rassemblees dans les documents du projet, destinees 
a alimenter des prises de decision, a soulever des points a traiter, a engager des actions ou a sensibiliser. 
Comme exemples, on peut citer les rapports d’etat, les memos, les justifications, les notes d’information, les 
tableaux de bord electroniques, les recommandations, et les mises a jour. 

La figure 1 -7 illustre le flux des informations du projet dans les differents processus utilises pour manager le projet. 
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Figure 1-7. Flux de donnees, d’informations et de rapports du projet 
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1.2.5 ADAPTATION 


En regie generate, les chefs de projet appliquent une methodologie de management de projet a leur travail. Une 
methodologie est un systeme de pratiques, de techniques, de procedures et de regies utilisees par les personnes 
travaillant dans une discipline. Cette definition montre que ce guide n’est pas une methodologie. 

Ce guide et le Standard pour le management de projet [1] sont des references recommandees pour I'adaptation de la 
methodologie a appliquer au projet, car ils identifient le sous-ensemble du corpus des connaissances en management 
de projet, generalement reconnu comme etant une bonne pratique. L'expression « bonne pratique » ne signifie pas 
que les connaissances decrites devraient etre appliquees de maniere systematique et uniforme a tous les projets. Les 
recommandations sur la methodologie n’entrent pas dans le champ de ce guide. 

Les methodologies du management de projet peuvent etre : 

♦ elaborees par des experts de I’organisation ; 

♦ achetees a des fournisseurs ; 

♦ obtenues aupres dissociations professionnelles ; 

♦ acquises aupres d’agences gouvernementales. 

Les processus, donnees d’entree, outils, techniques, donnees de sortie et phases du cycle de vie appropries doivent 
etre selectionnes en vue de manager un projet. Cette activite de selection est appelee adaptation du management 
de projet au projet. Dans le cadre de I’adaptation, le chef de projet collabore avec I’equipe projet, le sponsor, le 
management de I'organisation, ou une combinaison des trois. Dans certains cas, I’organisation peut avoir besoin de 
certaines methodologies en matiere de management de projet. 

L’adaptation est necessaire, car chaque projet est unique. De plus, les processus, les outils, les techniques, les 
donnees d’entree ou les donnees de sortie identifies dans le Guide PMBOK® ne sont pas tous requis pour les projets. 
L'adaptation devrait traiter des contraintes opposees en matiere de perimetre, d’echeancier, de cout, de ressources, 
de qualite et de risque. L'importance de chaque contrainte varie en fonction du projet. Le chef de projet adapte 
I'approche pour gerer ces contraintes selon I'environnement du projet, la culture organisationnelle, les besoins des 
parties prenantes et les autres variables. 

En adaptant le management de projet, le chef de projet devrait egalement tenir compte des divers niveaux de 
gouvernance requis qui regiront le projet mais aussi de la culture de I’organisation. De plus, les decisions d’adaptation 
du management de projet peuvent etre influences par I'appreciation du caractere interne ou externe du client par 
rapport a I’organisation. 

Les bonnes methodologies pour le management de projet tiennent compte de la nature unique des projets et 
accordent au chef de projet un certain degre d’adaptation. Cependant, I'adaptation incluse dans la methodologie peut 
tout de meme necessiter d’etre plus poussee pour un projet particulier. 
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1.2.6 DOCUMENTS BUSINESS DU MANAGEMENT DE PROJET 

Le chef de projet doit s’assurer que I'approche du management de projet saisit I’intention des documents business. 
Ces documents sont definis dans le tableau 1-5. Les deux documents sont non seulement interdependants mais aussi 
elabores et conserves de maniere iterative tout au long du cycle de vie du projet. 


Tableau 1-5. Documents business du projet 


Documents du projet 

Definition 

Business case du projet 

Le business case est une etude de faisabilite economique documentee destinee 
a s’assurer de la viabilite d’un investissement. II servira de base pour autoriser 
I’initialisation d’un projet. 

Plan de gestion des benefices du projet 

Explication documentee des processus de generation, d’optimisation 
et de perennisation des benefices issus d’un projet. 


En regie generate, il revient au sponsor du projet d'elaborer et de mettre a jour le business case du projet. Le 
chef de projet est, quant a lui, responsable de la formulation de recommandations et de la supervision afin d’assurer 
I’alignement des mesures de succes du business case, du plan de management, de la charte et du plan de gestion des 
benefices du projet entre elles mais aussi sur les buts et les objectifs de I'organisation. 

Le chef de projet devrait adapter les documents cites relatifs au management de projet de fagon appropriee pour 
ses projets. Dans certaines organisations, le business case et le plan de gestion des benefices sont conserves au 
niveau du programme. Les chefs de projet devraient collaborer avec les chefs de programme appropries afin de 
garantir I’alignement des documents du management de projet sur les documents du programme. La figure 1 -8 illustre 
I’interrelation entre ces documents business importants du management de projet et revaluation des besoins. Elle 
montre egalement une approximation du cycle de vie de ces divers documents par rapport au cycle de vie du projet. 
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Cycle de vie du projet 



Phases generiques 


Figure 1 -8. Interrelation entre revaluation des besoins et les documents cles de projet/de (’organisation 


1.2.6.1 BUSINESS CASE DU PROJET 

Le business case est une etude de faisabilite economique documentee destinee a s'assurer de la viabilite d’un 
investissement. II servira de base pour autoriser I’initialisation d’un projet. II contient les objectifs et les justifications du 
lancement d’un projet. De plus, il permet de mesurer le succes du projet par rapport a ses objectifs, lorsque celui-ci est 
arrive a son terme. Le business case est un document business du projet utilise tout au long du cycle de vie du projet. 
II peut etre utilise avant le lancement du projet et aboutir a une decision d’acceptation ou de rejet du projet. 

Le business case est souvent precede d’une evaluation des besoins dont le but est de comprendre les objectifs, les 
points a traiter et les opportunity et de recommander des propositions pour les traiter. Les resultats de revaluation des 
besoins peuvent etre resumes dans le business case. 
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Le processus de definition des besoins de I'organisation, d’analyse de la situation, de formulation de recommandations 
puis de definition des criteres devaluation s’applique atous les projets de I'organisation. Un business case peut inclure 
les points suivants: 

♦ Les besoins de I’organisation : 

■ determination des raisons qui poussent a Taction ; 

■ enonce de la situation documentant le point ou Topportunite a traiter, notamment la valeur a offrir a 
I'organisation; 

■ identification des parties prenantes concernees ; 

■ identification du perimetre. 

♦ Analyse de la situation : 

■ identification des strategies, des buts et des objectifs de I'organisation ; 

■ identification de la ou des causes originelles du probleme ou des principaux acteurs d’une opportunite; 

■ analyse de I’ecart entre les capacites necessaires au projet et les capacites existantes de I'organisation ; 

■ identification des risques connus ; 

■ identification des facteurs critiques de succes ; 

■ identification des criteres de decision utilises pour evaluer les differents plans d’action. 

Exemples de categories de criteres utilisees pour analyser une situation : 

o Requis. Ce critere doit etre obligatoirement satisfait pour traiter le probleme ou Topportunite. 
o Souhaite. II est souhaite de remplir ce critere pour traiter le probleme ou Topportunite. 
o Facultatif. Ce critere n’est pas essentiel. Lorsqu’il est rempli, il devient un element qui permet de faire la 
difference entre les autres plans d’action. 

■ Identification d’un ensemble d’options a prendre en compte pour traiter un probleme ou une opportunite 
d'affaire. Les options sont les autres plans d’action que I'organisation pourrait adopter. Elies peuvent 
egalement etre decrites comme des scenarios d’organisation. Par exemple, un business case peut presenter 
les trois options suivantes : 

o Ne rien faire. Cette option est egalement appelee«statu quo». En choisissant cette option, le projet n’est 
pas autorise. 

o Faire le minimum pour traiter le probleme ou I’opportunite. Le minimum peut etre etabli en identifiant 
Tensemble des criteres documents qui sont indispensables pour traiter le probleme ou Topportunite. 
o Faire plus que le minimum pour traiter le probleme ou I’opportunite. Cette option repond a Tensemble 
minimal des criteres ainsi qu’a d’autres criteres documents. Le business case peut documenter plus 
d’une de ces options. 
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♦ Recommandation: 

■ enonce de I’option recommandee pour poursuivre le projet; 

■ enonce pouvant inclure les elements suivants : 
o resultats d’analyse de I’option potentielle; 

o contraintes, hypotheses, risques et dependances des options potentielles ; 
o mesures de succes (voir la section 1.2.6.4). 

■ Une approche d’application pouvant inclure: 
o les jalons; 

o les dependances; 
o les roles et les responsabilites. 

♦ Evaluation: 

■ enonce decrivant le plan de mesure des benefices offerts par le projet. II devrait inclure tous les aspects 
operationnels en cours de I’option recommandee apres I'application initiale. 

Le business case constitue la base pour mesurer le succes et les progres realises tout au long du cycle de vie du 
projet en comparant les resultats aux objectifs et aux criteres de succes identifies. Consultez le document Business 
Analysis for Practitioners: A Practice Guide [7]. 
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1.2.6.2 PLAN DE GESTION DES BENEFICES DU PROJET 


Le plan de gestion des benefices du projet est un document qui decrit comment et quand les benefices du projet 
seront obtenus. II decrit egalement les mecanismes a mettre en place pour mesurer ces benefices. Un benefice du projet 
est defini comme I'aboutissement d'actions, comportements, produits, services ou resultats, qui fournit de la valeur 
a I’organisation sponsor ainsi qu’aux beneficiaires vises du projet. L'elaboration d’un plan de gestion des benefices 
intervient au debut du cycle de vie du projet avec la definition des benefices cibles a obtenir. Le plan de gestion des 
benefices decrit les elements cles des benefices. II comprend notamment les elements suivants : 

♦ benefices cibles (par exemple, la valeur tangible et intangible prevue resultant de I'application du projet ; 
la valeur financier est exprimee en tant que valeur actuelle nette); 

♦ alignement strategique (par exemple, dans quelle mesure les benefices du projet s’alignent sur les strategies 
de I'organisation); 

♦ delai de realisation des benefices (par exemple, les benefices par phase, a court terme, a long terme et recurrents); 

♦ charge de benefice (par exemple, la personne chargee de suivre, de consigner et de signaler les benefices 
obtenus dans le delai fixe par le plan); 

♦ mesures (par exemple, les mesures a utiliser pour montrer les benefices obtenus, les mesures directes et les 
mesures indirectes); 

♦ hypotheses (par exemple, les facteurs qui devraient etre en place ou en evidence); 

♦ risques (par exemple, les risques inherents a la realisation des benefices). 

Pour elaborer le plan de gestion des benefices, il convient d’utiliser les donnees et les informations documentees 
dans le business case et revaluation des besoins. Par exemple, les analyses couts-benefices consignees dans les 
documents illustrent I’estimation des couts par rapport a la valeur des benefices issus du projet. Le plan de gestion des 
benefices et le plan de management du projet decrivent comment la valeur resultant du projet devient partie integrate 
des operations en cours de I’organisation, y compris les metriques a utiliser. Les metriques permettent de verifier la 
valeur et de valider le succes du projet. 

Le processus d’elaboration et de conservation du plan de gestion des benefices du projet est une activite iterative. 
Ce document complet le business case, la charte du projet et le plan de management du projet. Le chef de projet 
collabore avec le sponsor afin de garantir que la charte du projet, le plan de management du projet et le plan de 
gestion des benefices restent alignes tout au long du cycle de vie du projet. Consultez les documents Business 
Analysis for Practitioners: A Practice Guide [7], The Standard for Program Management [3], et The Standard for 
Portfolio Management [2]. 
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1.2.6.3 CHARTE DU PROJET ET PLAN DE MANAGEMENT DU PROJET 


La charte du projet est definie comme le document emis par le sponsor du projet. Elle autorise formellement I’existence 
du projet et donne autorite au chef de projet pour affecter des ressources de I’organisation aux activites du projet. 

Le plan de management du projet est le document qui decrit comment le projet sera execute et suivi. 

Consultez la section 4 sur la gestion de I’integration du projet pour obtenir plus d'informations sur la charte du projet 
et le plan de management du projet. 

1.2.6.4 MESURES DE SUCCES DU PROJET 

Dans le management de projet, I’une des difficulty les plus courantes est de determiner si le projet est ou n’est pas 
un succes. 

Le succes d’un projet etait traditionnellement defini par les mesures du temps, du cout, du perimetre et de la qualite 
du management de projet. Plus recemment, professionnels et specialistes ont montre que le succes du projet doit 
egalement etre mesure en tenant compte de la realisation des objectifs du projet. 

Les parties prenantes du projet peuvent avoir une perception differente du succes d’un projet ou de la priorite des 
facteurs. II est important d’enoncer clairement les objectifs du projet et de choisir des objectifs mesurables. Les parties 
prenantes cles et le chef de projet doivent repondre a trois questions : 

♦ Qu’est-ce qui determine le succes de ce projet ? 

♦ Comment mesurer le succes ? 

♦ Quels sont les facteurs qui peuvent impacter le succes ? 

Les reponses a ces questions doivent etre documentors et accepters par les parties prenantes cles et le chef 
de projet. 

Le succes du projet peut inclure d’autres criteres lies a la strategie de I'organisation et a I’obtention des resultats. Ces 
objectifs du projet sont notamment: 

♦ realiser le plan de gestion des benefices du projet; 

♦ respecter les mesures financiers enoncees dans le business case. Ces mesures financiers comprennent, 

entre autres: 

■ la valeur actuelle nette (NPV); 

■ le retour sur investissement (ROI); 

■ le taux interne de rentabilite (IRR); 

■ le temps de retour sur investissement (PBP); 

■ le rapport couts/benefices (BCR); 
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♦ atteindre les objectifs non financiers du business case; 

♦ realiser le passage de I'etat actuel de I'organisation a son etatfutur souhaite ; 

♦ respecter les conditions generates du contrat; 

♦ realiser la strategie, les buts et les objectifs de I’organisation ; 

♦ satisfaire les parties prenantes; 

♦ garantir I'adoption par les utilisateurs finaux/clients ; 

♦ integrer les livrables a I'environnement operationnel de I'organisation ; 

♦ assurer le niveau de qualite de prestation convenu ; 

♦ remplir les criteres de gouvernance; 

♦ appliquer les autres criteres ou mesures du succes (par exemple, le rendement du processus). 

L’equipe projet doit etre capable d’evaluer la situation du projet, d’equilibrer les demandes et d'assurer une 
communication proactive avec les parties prenantes pour aboutir au succes du projet. 

Lorsque I'alignement commercial d’un projet ne change pas, les chances de succes du projet sont bien plus grandes 
parce que le projet reste aligne avec la direction strategique de I’organisation. 

Le projet peut etre un succes du point de vue du perimetre, de I’echeancier ou du budget et un echec du point de 
vue commercial. Ceci peut se produire lorsque les besoins de I’organisation ou I’environnement du marche changent 
avant la fin du projet. 
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2 


ENVIRONNEMENT DU PROJET 


2.1 PRESENTATION 

Les projets evoluent dans des environnements susceptibles de les influencer. Ces influences peuvent etre favorables 
ou defavorables au projet. II existe deux grandes categories d’influences, a savoir les facteurs environnementaux de 
I’organisation (EEF) et les actifs organisationnels. 

Les facteurs environnementaux de I’organisation sont issus de I’environnement exterieur au projet et a I’organisation. 
Ils peuvent avoir un impact au niveau de I'organisation, du portefeuille, du programme ou du projet. Pour obtenir des 
informations complementaires sur les facteurs environnementaux de I’organisation, consultez la section 2.2. 

Les actifs organisationnels sont internes a I'organisation. Ils peuvent provenir de I’organisation, d’un portefeuille, 
d’un programme, d’un autre projet ou d’une association de ces elements. La figure 2-1 montre les influences du 
projet sur les facteurs environnementaux de I’organisation et les actifs organisationnels. Pour obtenir des informations 
complementaires sur les actifs organisationnels, consultez la section 2.3. 


Influences 


Facteurs 


Actifs 

environnementaux 


organisationnels 

de I’organisation 


de I’organisation 






Externes 


Internes 




Processus, 
politiques internes 
et procedures 


Base 

de connaissance 
de I'organisation 


Figure 2-1. Influences du projet 


Outre les facteurs environnementaux de I’organisation et les actifs organisationnels, les systemes de I’organisation 
jouent un role important dans le cycle de vie du projet. Les facteurs du systeme qui ont un impact sur le pouvoir, I’influence, 
les interets, les competences et les capacites politiques des personnes a agir dans le systeme de I’organisation sont 
traites plus loin dans la section correspondante (voir la section 2.4). 
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2.2 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Les facteurs environnementaux de I’organisation designent les conditions qui ne sont pas sous le controle immediat 
de I’equipe projet, et qui influencent, contraignent ou dirigent le projet. Ces conditions peuvent etre internes ou externes 
a I’organisation. Les facteurs environnementaux de I'organisation sont considers comme des donnees d’entree pour 
de nombreux processus de management de projet, notamment pour la plupart des processus de planification. Ms 
peuvent etre favorables ou defavorables aux options de management de projet et peuvent avoir une influence positive 
ou negative sur le resultat. 

La nature ou le type des facteurs environnementaux de I’organisation sonttres varies. II convient de prendre en compte 
ces facteurs pour le succes du projet. Les paragraphes 2.2.1 et 2.2.2 abordent certains facteurs environnementaux 
de I’organisation. 


2.2.1 LES FACTEURS ENVIRONNEMENTAUX INTERNES A ^ORGANISATION 

Les facteurs environnementaux de I'organisation suivants sont internes a I'organisation. 

♦ Culture, structure et gouvernance organisationnelles. Par exemple, la vision, la mission, les valeurs, les 
convictions, les normes culturelles, le style de leadership, la hierarchie et les relations d’autorite, le style 
organisationnel, I’ethique et la deontologie. 

♦ Repartition geographique des installations et des ressources. Par exemple, les sites de production, les 
equipes virtuelles, les systemes partages et le cloud computing. 

♦ Infrastructure. Par exemple, les installations existantes, les equipements, les moyens de telecommunication de 
I'organisation, le materiel informatique, la disponibilite et la capacite. 

♦ Logiciels informatiques. Par exemple, les outils logiciels de planification, les systemes de gestion de la 
configuration, les interfaces Web avec d'autres systemes automatises en ligne et les systemes d'autorisation 
de travail. 

♦ Disponibilite des ressources. Par exemple, les contraintes en matiere de contrats ou d'achats, les fournisseurs 
et les sous-traitants approuves et les accords de collaboration. 

♦ Aptitudes du personnel. Par exemple, les expertises, les capacites, les competences et les connaissances 
specialises disponibles. 
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2.2.2 FACTEURS ENVIRONNEMENTAUX EXTERNES A ^ORGANISATION 

Les facteurs environnementaux suivants sont externes a I’organisation. 

♦ Conditions du marche. Par exemple, les concurrents, les parts de marche, la notoriete de la marque et les 
marques commerciales. 

♦ Questions sociales et culturelles. Par exemple, le climat politique, la deontologie, I’ethique et les perceptions. 

♦ Restrictions legates. Par exemple, les lois et regimentations nationales ou locales relatives a la securite, a la 
protection des donnees, a la conduite professionnelle, a I’emploi et aux approvisionnements. 

♦ Bases de donnees commerciales. Par exemple, les resultats du benchmarking, les donnees normalisees 
d'estimation des couts, les informations provenant d’etudes de risque dans I’industrie et les bases de donnees 
des risques. 

♦ Recherche academique. Par exemple, les etudes et les publications du secteur ainsi que les resultats du 
benchmarking. 

♦ Standards gouvernementaux ou industriels. Par exemple, les standards et les regimentations des organismes 
de normalisation relatives aux produits, a la production, a I’environnement, a la qualite et a la fabrication. 

♦ Considerations financiers. Par exemple, is taux de change, is taux d'interet, is taux d’inflation, is tarifs et 
la situation geographique. 

♦ Elements environnementaux materiels. Par exemple, is conditions de travail, la meteo et is contraintes. 


2.3 ACTIFS ORGANISATIONNELS 

Les actifs organisationnels comprennent is plans, processus, politiques internes, procedures et bases de 
connaissances specifiques et utilises par I'organisation realisatrice. Ces actifs organisationnels influencent le 
management du projet. 

Ms comprennent tout objet, pratique ou connaissance provenant de toutes is organisations realisatrices participant 
au projet et qui peuvent etre utilises pour realiser ou regir le projet. Ils comprennent egalement is retours d’experience 
de projets anterieurs et is donnees historiques de I'organisation. Les actifs organisationnels peuvent inclure des 
echeanciers, des donnees sur is risques et des donnees de valeur acquise. Ce sont des donnees d’entree pour 
la plupart des processus de management de projet. Les actifs organisationnels etant internes a I'organisation, is 
membres de I'equipe projet peuvent, selon is besoins, is mettre a jour et is completer tout au long du projet. Les 
actifs organisationnels peuvent etre regroupes en deux categories : 

♦ is processus, politiques internes et procedures; 

♦ is bases de connaissance de I'organisation. 
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En regie generate, les actifs de la premiere categorie ne sont pas mis a jour dans le cadre du projet. Les processus, 
politiques internes et procedures sont generalement etablis par le bureau des projets (Project Management Office, PMO) 
ou une autre fonction exterieure au projet. Ces processus, politiques internes ou procedures peuvent uniquement etre 
mis a jour en respectant les politiques internes correspondantes de I’organisation. Certaines organisations encouragent 
I’equipe a adapter les modeles, les cycles de vie et les listes de controle a chaque projet. Dans ce cas, I'equipe de 
management de projet devrait adapter ces actifs afin de repondre aux besoins du projet. 

Les actifs de la seconde categorie sont constamment mis a jour a I'aide des informations du projet. II s'agit, par 
exemple, des informations sur la performance financier, les retours d’experience, les problemes et les indicateurs de 
performance mais aussi les defauts qui sont corriges au fil du projet. 


2.3.1 PROCESSUS, POLITIQUES INTERNES ET PROCEDURES 

Les processus et les procedures de I’organisation qui permettent de realiser le projet incluent les elements suivants: 

4 Initialisation et planification: 

■ des directives et des criteres d’adaptation de I’ensemble des procedures et des processus standardises de 
I'organisation, pour satisfaire les besoins particuliers du projet; 

■ des standards organisationnels specifiques, tels que les politiques internes (par exemple, les politiques 
de ressources humaines, de sante et de securite, de confidentialite, de qualite, d'approvisionnement et 
d’environnement); 

■ des cycles de vie du produit et du projet, ainsi que les methodes et procedures (par exemple, les methodes 
de management de projet, les metriques d’estimation, les audits de processus, les objectifs d’amelioration, 
les listes de controle et les definitions de processus normalisees a usage interne); 

■ des modeles (par exemple, les plans de management de projet, les documents de projet, les registres de 
projet, les formats des rapports, les modeles de contrat, les categories de risque, les modeles d’enonce de 
risque, les definitions de probabilite et d’impact, les matrices de probabilite et d'impact et les modeles de 
registre des parties prenantes); 

■ des listes de fournisseurs preapprouves et differents types d’accords contractuels (par exemple, les contrats 
a prix fixe, a couts remboursables et en regie). 

4 Execution et maitrise: 

■ des procedures de maitrise des changements, comprenant les regies de changement des standards de 
I'organisation realisatrice, des politiques internes, des plans et procedures, ou de tout autre document de 
projet, ainsi que les modalites d’approbation et de validation de ces changements; 

■ des matrices de tragabilite ; 

■ des procedures de controle financier (par exemple, le systeme de declaration du temps de travail, les revues 
requises de depenses et de debours, les codes d’imputation comptable et les provisions contractuelles 
standardises); 
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■ des procedures de gestion des points a traiter et des defauts, qui definissent les controles correspondents, 
I'identification et la resolution de ces problemes et defauts, et qui font le suivi des actions point par 
point, notamment; 

■ la gestion de la maTtrise de la disponibilite des ressources et des affectations ; 

■ des exigences de I’organisation en matiere de communication (par exemple, la disponibilite d’unetechnologie 
de communication particuliere, les medias autorises, les politiques de stockage des enregistrements, la 
videoconference, les outils collaboratifs et les exigences de securite); 

■ des procedures visant a prioriser, a approuver et a emettre des autorisations de travaux ; 

■ des modeles (par exemple, le registre des risques, le journal des points a traiter et le journal des changements); 

■ des directives, des instructions de travail, des criteres devaluation des propositions et des criteres de 
mesure de performance, tous ces elements etant standardises ; 

■ des procedures de verification et de validation des produits, des services ou des resultats. 

♦ Cloture : des directives ou des exigences liees a la cloture du projet (par exemple, les audits finaux du projet, 

les evaluations du projet, I'acceptation des livrables, la cloture du contrat, la reaffectation des ressources et le 

transfer! des connaissances a la production ou aux operations). 


2.3.2 ARCHIVES DES CONNAISSANCES DE [.’ORGANISATION 

Les archives de connaissances de [organisation qui integrent et stockent les informations, incluent, en particulier: 

♦ des archives de connaissance de la gestion de la configuration, contenant les versions des logiciels et materiels 
ainsi que les references de base de [ensemble des procedures, des politiques internes, des standards de 
[organisation realisatrice ettous les documents du projet; 

♦ des archives de donnees financieres contenant des informations telles que les heures de travail, les couts 
encourus, les budgets et tout depassement de cout du projet; 

♦ des informations historiques et des archives de donnees des retours d’experience (par exemple, des 
enregistrements et des documents du projet, toute information et documentation de cloture du projet, des 
informations relatives aux resultats des decisions anterieures de selection de projet et aux performances de 
projets anterieurs, et des informations sur les activites de management des risques); 

♦ des archives de donnees sur le management des points a traiter et des defauts, contenant I’etat de ces elements, 
les informations sur leur maTtrise, leur resolution et les resultats des actions ; 

♦ des archives de donnees des metriques utilisees pour recueillir et mettre a disposition les donnees de mesures 
sur les processus et produits; 

♦ des fichiers de projets anterieurs (par exemple, les references de base du perimetre, de I'echeancier, des couts 
et de la performance, les calendriers du projet, les diagrammes de reseau du projet, les registres des risques, les 
rapports sur les risques et les registres des parties prenantes). 
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2.4 SYSTEMES DE ^ORGANISATION 


2.4.1 PRESENTATION 

Les projets sont soumis aux contraintes imposees par I’organisation par le biais de leur structure et leur cadre de 
gouvernance. Pour etre efficace, le chef de projet doit comprendre ou se situent la responsabilite, I’obligation de rendre 
compte et I’autorite au sein de I’organisation. Ainsi, il pourra mieux utiliser son pouvoir, son influence, ses competences, 
son leadership et ses aptitudes politiques pour terminer le projet. 

L’interaction de plusieurs facteurs dans une organisation cree un systeme unique qui influence le fonctionnement 
du projet dans ce systeme. Le systeme qui en resulte determine le pouvoir, I’influence, les interets, les competences et 
les aptitudes politiques des personnes a meme d’agir dans ce systeme. Parmi les facteurs du systeme, on peut citer: 

♦ les elements de management; 

♦ les cadres de gouvernance; 

♦ les types de structures organisationnelles. 

Les informations et explications exhaustives des facteurs du systeme de I'organisation ainsi que I’influence de la 
combinaison de ces facteurs sur un projet depassent le champ de ce guide. II existe des disciplines, accompagnees 
d’une documentation, de methodologies et de pratiques, qui etudient ces facteurs de fagon plus approfondie qu’il ne 
serait possible avec ce guide. Cette section presente ces facteurs et leurs relations. 

Cette presentation commence par aborder les systemes de maniere generate. Un systeme est un groupe de composants 
qui, ensemble, produisent des resultats impossibles a obtenir avec un seul composant. Un composant est un element 
identifiable dans le projet ou I’organisation qui assure une fonction particuliere ou un groupe de fonctions connexes. 
L'interaction des divers composants du systeme cree les capacites et la culture de I’organisation. Les systemes sont 
regis par plusieurs principes : 

♦ Les systemes sont dynamiques. 

♦ Les systemes peuvent etre optimises. 

♦ Les composants systemes peuvent etre optimises. 

♦ Les systemes et leurs composants ne peuvent pas etre optimises en meme temps. 

♦ Les systemes ne sont pas lineaires en termes de reactivite. (Un changement des donnees d’entree n’entrame 
pas un changement previsible des donnees de sortie.) 
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Plusieurs changements peuventse produire au niveau du systeme mais aussi entre le systeme etson environnement. 
Lorsque ces changements ont lieu, un comportement adaptatif s'opere dans les composants qui, a leur tour, s'ajoutent 
aux dynamiques du systeme. Les dynamiques du systeme sont definies par I’interaction entre les composants en 
fonction des relations et des dependances qui existent entre les composants. 

Les systemes relevent generalement de la responsabilite de la direction d’une organisation. Cette derniere examine 
les compromis en matiere d’optimisation entre les composants et le systeme afin de prendre les mesures qui s’imposent 
pour obtenir les meilleurs resultats pour I’organisation. Les resultats de cet examen influenceront le projet a I'etude. Par 
consequent, le chef de projet doit tenir compte de ces resultats lorsqu’il determines la fagon d’atteindre les objectifs 
du projet. De plus, il doit tenir compte du cadre de gouvernance de I’organisation. 


2.4.2 CADRES DE GOUVERNANCE DE L’ORGANISATION 

Selon les recentes recherches de PMI, la gouvernance designe les dispositions organisationnelles ou structurelles 
a tous les niveaux d’une organisation visant a determiner et a influencer le comportement de ses membres [9]. Ces 
recherches indiquent que le concept de gouvernance est multidimensionnel et: 

♦ tient compte des personnes, des roles, des structures et des politiques internes ; 

♦ necessite d'assurer une direction et une supervision grace aux donnees et aux retours d'information. 

2.4.2.1 CADRE DE GOUVERNANCE 

La gouvernance est le cadre dans lequel I’autorite est exercee au sein des organisations. Ce cadre inclut, notamment: 

♦ les regies; 

♦ les politiques internes ; 

♦ les procedures; 

♦ les normes; 

♦ les relations; 

♦ les systemes; 

♦ les processus. 

Ce cadre influence: 

♦ la definition et la realisation des objectifs de I’organisation ; 

♦ la martrise et revaluation des risques; 

♦ I’optimisation des performances. 
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2.4.2.2 GOUVERNANCE DES PORTEFEUILLES, DES PROGRAMMES ET DES PROJETS 

Le document Governance of Portfolios, Programs, and Projects: A Practice Guide [10] decrit le cadre de gouvernance 
commun qui aligne le management de projet organisationnel (OPM) ainsi que le management de portefeuille, de 
programme et de projet. II presente les quatre domaines de gouvernance que sont I’alignement, les risques, la 
performance et les communications. Chaque domaine a pour fonctions la supervision, la maTtrise, I’integration et la 
prise de decision. Chaque fonction a des activites et des processus de gouvernance pour des projets autonomes ou 
des projets evoluant dans des environnements de portefeuille ou de programme. 

La gouvernance du projet designe le cadre, les fonctions et les processus qui guident les activites de management 
de projet afin de developper un service, un produit ou un resultat unique permettant d'atteindre des objectifs 
organisationnels, strategiques et operationnels. Chaque organisation a son propre cadre de gouvernance. Pour 
etre efficace, il conviendrait d’adapter le cadre de gouvernance a la culture, au type de projet et aux besoins de 
I'organisation. 

Pour obtenir plus d’informations sur la gouvernance du projet, y compris son application, consultez le document 
Governance of Portfolios, Programs, and Projects: A Practice Guide [10]. 


2.4.3 ELEMENTS DE MANAGEMENT 

Les elements de management sont les composants qui constituent les fonctions ou les principes cles du management 
de I'organisation. Les elements de management sont attribues au sein de I'organisation en fonction de son cadre de 
gouvernance et du type de structure organisationnelle choisi. 

Les fonctions ou les principes cles du management comprennent notamment: 

♦ la division du travail realisee a I’aide de competences specialises et de la disponibilite pour effectuer le travail; 

♦ I’autorite conferee pour effectuer un travail; 

♦ la responsabilite pour realiser un travail correctement assigne en fonction d’attributs comme la competence 
et experience; 

♦ la discipline dans Faction (par exemple, le respect de I'autorite, des personnes et des regies); 

♦ I’unicite de commande (par exemple, seule une personne donne des instructions a la personne pour une action 
ou une activite); 

♦ I'unicite de direction (par exemple, un plan et un responsable pour un groupe d'activites ayant le meme objectif); 

♦ la prevalence des objectifs globaux de I’organisation sur les objectifs individuels ; 

♦ la remuneration equitable pour le travail accompli; 
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♦ I’utilisation optimale des ressources ; 

♦ les canaux de communication clairs ; 

♦ I’attribution des materiels appropries aux personnes adequates au moment opportun pour la bonne tache; 

♦ le traitement juste et equitable des personnes sur le lieu de travail; 

♦ la securite assuree aux postes de travail; 

♦ la surete des personnes sur le lieu de travail; 

♦ la contribution ouverte de chaque personne a la planification et a I'execution ; 

♦ un moral optimal. 

La performance de ces elements est attribute a certaines personnes de I'organisation qui peuvent exercer les 
fonctions citees dans differentes structures organisationnelles. Par exemple, dans une structure hierarchique, il existe 
des niveaux verticaux et horizontaux au sein de I'organisation. Cette hierarchie s’etend du niveau superieur hierarchique 
au niveau executif. La responsabilite, I’obligation de rendre compte et I’autorite assignees au niveau hierarchique 
indiquent comment la personne peut exercer sa fonction dans cette structure organisationnelle. 


2.4.4 TYPES DE STRUCTURES ORGANISATIONNELLES 

Le type de structure organisationnelle adequat est determine apres avoir etudie les compromis entre deux variables 
cles. Les variables sont les types de structures organisationnelles disponibles et leur optimisation pour une organisation 
donnee. Chaque organisation a sa propre structure. La structure finale d’une organisation donnee est unique en raison 
des nombreuses variables dont il faut tenir compte. Les sections 2.4.4.1 et 2.4.4.2 donnent des exemples de certains 
des facteurs a inclure lors de la prise en compte des deux variables donnees. La section 2.4.4.3, quant a elle, traite d’une 
structure organisationnelle qui prevaut dans le management de projet. 

2.4.4.1 TYPES DE STRUCTURES ORGANISATIONNELLES 

Les structures organisationnelles se presented sous de multiples formes ou types. Le tableau 2-1 compare plusieurs 
types d'organisation et leur influence sur les projets. 
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2.4.4.2 FACTEURS DE SELECTION D’UNE STRUCTURE ORGANISATIONNELLE 

Chaque organisation tient compte de nombreux facteurs a inclure dans sa structure. Les facteurs ont chacun leur 
niveau d’importance dans I'analyse finale. L'association du facteur, de sa valeur et de son importance relative permet 
aux decideurs de I'organisation d’obtenir les bonnes informations qu’ils integreront a I'analyse. 

Les facteurs a prendre en compte lors de la selection d’une structure organisationnelle sont, entre autres: 

♦ le niveau d'alignement avec les objectifs de I'organisation ; 

♦ les capacites de specialisation ; 

♦ I'efficacite et efficience de I'etendue des responsabilites (ou«span of control»); 

♦ une procedure claire d’escalade des decisions ; 

♦ une structure et des limites claires de la hierarchie ; 

♦ les capacites de delegation ; 

♦ I’affectation des obligations de rendre compte ; 

♦ (’affectation des responsabilites; 

♦ I’adaptabilite de la conception ; 

♦ la simplicity de la conception ; 

♦ I’efficacite des performances ; 

♦ les considerations de cout; 

♦ les lieux physiques (par exemple, regroupes, regionaux et virtuels); 

♦ une communication claire (par exemple, les politiques internes, I’etat d’avancement des travaux et la vision 
de ^organisation). 
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Tableau 2-1. Influences des structures organisationnelles sur les projets 


Type de structure 
organisationnelle 

> 

Caracteristiques du projet 

Groupes 

de travail etablis 

selon: 

Autorite 
du chef 
de projet 

Role 

du chef 
de projet 

Disponibilite 
des ressources 

Qui gere 
le budget 
du projet? 

Equipe 

administrative 
de management 
de projet 

Organique 
ou simple 

Flexible; membres 
travaillant main 
dans la main 

Peu voire aucune 

Temps partiel; 
peut etre 
un coordinateur 
designe ou non 

Peu voire aucune 

Responsable 
ou operateur 

Peu voire aucune 

Fonctionnelle 

(centralisee) 

Travail en cours 
d’execution 
(ingenierie, 
fabrication) 

Peu voire aucune 

Temps partiel; 
peut etre 
un coordinateur 
designe ou non 

Peu voire aucune 

Responsable 

fonctionnel 

Temps partiel 

Multidivisionnelle 
(peut repeter 
des fonctions pour 
chaque division 
avec peu 
de centralisation) 

Un element parmi 
les suivants: 
produit, processus 
de production, 
portefeuille, 
programme, region 
geographique, type 
de client 

Peu voire aucune 

Temps partiel; 
peut etre 
un coordinateur 
designe ou non 

Peu voire aucune 

Responsable 

fonctionnel 

Temps partiel 

Matrice - solide 

Par fonction, chef 
de projet etant 
une fonction 

Moderee a elevee 

Fonction 
professionnelle 
a temps plein 

Moderee a elevee 

Chef de projet 

Temps plein 

Matrice - faible 

Fonction 

Faible 

Temps partiel; 
dans le cadre 
d'un autre travail 
et non pas en tant 
que coordinateur 
designe 

Faible 

Responsable 

fonctionnel 

Temps partiel 

Matrice - equilibree 

Fonction 

Faible a moderee 

Temps partiel; 
integre dans 
les fonctions 

comme une 
competence et pas 
forcement en tant 
que coordinateur 
designe 

Faible a moderee 

Melange 

Temps partiel 

Orientee projet 

(composite, 

hybride) 

Projet 

Elevee a quasi 
total e 

Fonction 
professionnelle 
a temps plein 

Elevee a quasi 
total e 

Chef de projet 

Temps plein 

Virtuelle 

Structure 
de reseau avec 
noeuds aux points 
de contact avec 
d’autres personnes 

Faible a moderee 

Temps plein ou 
temps partiel 

Faible a moderee 

Melange 

Temps plein ou 
temps partiel 

Hybride 

Melange d’autres 
types 

Melange 

Melange 

Melange 

Melange 

Melange 

PMO* 

Melange d’autres 
types 

Elevee a quasi 
total e 

Fonction 
professionnelle 
a temps plein 

Elevee a quasi 
total e 

Chef de projet 

Temps plein 


*PMO designe le bureau des projets. 
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2.4.4.3 BUREAU DES PROJETS (PROJECT MANAGEMENT OFFICE, PMO) 


Un bureau des projets (Project Management Office, PMO) est une structure organisationnelle qui normalise les 
processus de gouvernance des projets et facilite le partage des ressources, des methodologies, des outils et des 
techniques entre les projets. Les responsabilites d’un bureau des projets peuvent aller de la fourniture de fonctions de 
soutien pour le management de projet jusqu’au management direct d’un ou de plusieurs projets. 

II existe plusieurs types de PMO au sein des organisations, qui different en termes du degre de controle et de 
I’influence qu’ils exercent sur les projets au coeur de I’organisation, notamment les suivants : 

♦ Soutenant. Les bureaux des projets de type soutenant fournissent un soutien consultatif aux projets en offrant 
des modeles, des bonnes pratiques, de la formation, un acces aux informations et aux retours d’experience 
d’autres projets. Ce type de bureau des projets fait office d'archive pour les projets. Le degre de maTtrise assume 
par ce bureau des projets est faible. 

♦ Conformite. Les bureaux des projets de type conformite apportent leur soutien et exigent la conformite par differents 
moyens. Le degre de maTtrise assume par ce bureau des projets est modere. La conformite peut impliquer: 

■ I’adoption de cadres ou de methodologies de management de projet; 

■ I’utilisation de modeles, de formulaires et d’outils; 

■ la conformite aux cadres de gouvernance. 

♦ Directif. Les bureaux des projets de type directif prennent en charge la maTtrise des projets en les manageant 
directement. Les chefs de projet sont designes par le bureau des projets et relevent de ce dernier. Le niveau de 
maTtrise assume par ce bureau des projets est eleve. 

Le bureau des projets peut avoir une responsabilite a I'echelle de I'organisation. II joue un role dans lesoutien a I'alignement 
strategique et la creation de valeur organisationnelle. Le bureau des projets integre les donnees et les informations des 
projets strategies de I’organisation, et evalue comment les objectifs strategies de plus haut niveau sont atteints. 
Le bureau des projets est la liaison naturelle entre les portefeuilles, les programmes, les projets de I’organisation et les 
systemes de mesure organisationnels (par exemple, balanced scorecard ou tableau de bord prospectif). 

Les projets qui regoivent un support du bureau des projets, ou qui sont diriges par lui, peuvent ne pas etre apparentes, 
bien qu'ils soient geres ensemble. La forme, la fonction et la structure particulieres d’un bureau des projets dependent 
des besoins de I'organisation qu'il soutient. 
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Un bureau des projets peut avoir I’autorite d’agir en tant que partie prenante a part entiere et etre un decideur cle tout 
au long de la vie de chaque projet, de fagon a rester aligne sur les objectifs de I’organisation. Le bureau des projets peut: 

♦ formuler des recommandations; 

♦ diriger le transfert des connaissances ; 

♦ mettre fin a des projets; 

♦ entreprendre d’autres actions, si besoin, 

Une fonction cle du bureau des projets est d’apporter aux chefs de projet un soutien qui peut revetir divers 
aspects, comme: 

♦ la gestion des ressources partagees entre tous les projets geres par le bureau des projets ; 

♦ I'identification et le developpement d’une methodologie de management de projet, de bonnes pratiques et 
de standards; 

♦ Le coaching, le mentorat, la formation et la supervision ; 

♦ la maTtrise, au moyen des audits de projet, de la conformite aux standards, aux politiques internes, aux procedures 
et aux modeles de documents de management de projet; 

♦ (’elaboration et la gestion de politiques internes, de procedures, de modeles et d’autres documentations partagees 
(actifs organisationnels); 

♦ la coordination de la communication entre les projets. 
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LE ROLE DU CHEF DE PROJET 


3.1 PRESENTATION 

Le chef de projet joue un role essentiel dans I’exercice du leadership sur une equipe projet afin d’atteindre les 
objectifs du projet. Ce role est clairement perceptible tout au long du projet. Si, dans la plupart des cas, le chef de projet 
participe au projet du debut a la fin, dans certaines organisations, il peut prendre part aux activites devaluation et 
d’analyse preambles au lancement du projet. Ces activites comprennent notamment la consultation des responsables de 
division operationnelle ou des dirigeants sur les idees de developpement des objectifs strategies, d’amelioration des 
performances de I’organisation ou de satisfaction des besoins du client. Dans certaines structures organisationnelles, 
le chef de projet peut egalement etre appele a gerer ou a contribuer a la business analyse, a (’elaboration du business 
case et aux aspects du management de portefeuille d’un projet. Le chef de projet peut egalement etre implique dans 
les activites de suivi liees a la realisation des benefices du projet. Son role peut varier d’une organisation a I’autre. En 
fin de compte, le role du management de projet est adapte a ('organisation tout comme les processus du management 
de projet sont adaptes au projet. 

Une simple analogie peut aider a comprendre les roles du chef d’un grand projet en les comparant aux roles du chef 
d’un grand orchestre. 

♦ Membres et roles. Projets de grande envergure et orchestres se composent de nombreux membres, chacun 
investi d’un role different. D’un cote, un grand orchestre peut compter plus de 100 musiciens diriges par un chef 
d’orchestre. Les musiciens peuvent jouer 25 sortes d'instruments differents appartenant aux grandes families, 
c’est-a-dire les cordes, les bois, les cuivres et les percussions. De I'autre cote, un grand projet peut compter 
aussi plus de 100 membres diriges par un chef de projet. Les membres d’equipe peuvent accomplir de nombreux 
roles differents, comme la conception, la fabrication et la gestion des installations. A I’instar des grandes families 
de I’orchestre, ces taches represented les divisions ou les groupes d’une organisation. Les musiciens et les 
membres du projet constituent Pequipe du chef. 

♦ Responsabilite envers I’equipe. Le chef de projet et le chef d’orchestre sont tous deux responsables de ce que 
produit leur equipe, a savoir I’aboutissement du projet ou le concert symphonique, respectivement. Les deux 
chefs doivent avoir une vision globale des produits de leur equipe afin de les planifier, de les coordonner et de les 
achever. Ms commencent par passer en revue la vision, la mission et les objectifs de leur organisation respective 
afin de garantir I’alignement avec leurs produits. Ms etablissent leur interpretation de la vision, de la mission et 
des objectifs necessaires au bon achevement de leurs produits. Enfin, les deux chefs utilisent leur interpretation 
pour communiquer et motiver leur equipe en vue de realiser leurs objectifs. 
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♦ Oonnaissances et competences. 

■ Le chef d’orchestre n’est pas cense savoir jouer de tous les instruments. En revanche, il doit posseder une 
comprehension, une experience et des connaissances musicales. II assure a I'orchestre une direction, une 
planification et une coordination par le biais de communications. Le chef d’orchestre communique par ecrit 
avec les partitions musicales et le calendrier des repetitions. II communique egalement en temps reel avec 
son equipe a I'aide d’une baguette et d’autres mouvements du corps. 

■ Le chef de projet n’est pas cense accomplir tous les roles du projet. En revanche, il doit posseder des 
connaissances en management de projet ainsi qu’une comprehension, une experience et des connaissances 
techniques. II assure a I'equipe projet une direction, une planification et une coordination par le biais 
de communications. Le chef de projet communique par ecrit (par exemple, les echeanciers et les plans 
documents) et en temps reel avec I’equipe par le biais de reunions et d’indices verbaux ou non verbaux. 

Le reste de cette section traite des principaux aspects du role du chef de projet. S’il existe des milliers de livres et 
d’articles sur le sujet, cette section n’entend pas couvrir toutes les informations disponibles. Elle presente plutot un 
apergu qui permet au professionnel d’acquerir les connaissances de base sur le sujet en vue de se preparer a une etude 
plus concentree sur les divers aspects abordes. 


3.2 DEFINITION DU CHEF DE PROJET 

Le role du chef de projet est different de celui d’un responsable fonctionnel ou d’un responsable des operations. 
Habituellement, le responsable fonctionnel concentre son travail sur la gestion du suivi d’un centre fonctionnel ou de 
profit, alors que le responsable des operations est charge d’assurer I’efficacite des operations. Le chef de projet est la 
personne designee par I’organisation realisable pour diriger I’equipe chargee d’atteindre les objectifs du projet. 


3.3 LA SPHERE D’INFLUENCE DU CHEF DE PROJET 

3.3.1 PRESENTATION 

Le chef de projet remplit de nombreux roles dans sa sphere d’influence. Ces roles refletent ses capacites et 
represented la valeur et les contributions au metier du management de projet. Cette section presente les roles du chef 
de projet dans les differentes spheres d’influence illustrees a la figure 3-1. 
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Parties prenantes 
Fournisseurs 
Clients 

Utilisateurs finaux 


Sponsors 

Instances dirigeantes 
Comites de direction 
Bureaux des projets 



Figure 3-1. Exemple de sphere d’influence du chef de projet 


3.3.2 LE PROJET 

Le chef de projet dirige I’equipe projet afin d’atteindre les objectifs du projet et de repondre aux attentes des parties 
prenantes. II s’efforce de trouver un equilibre entre les contraintes divergentes du projet et la disponibilite des ressources. 

Le chef de projet assume egalement un role de communication entre le sponsor du projet, les membres de I’equipe et 
les autres parties prenantes. II s’agit, notamment, de donner une orientation et de partager la vision du succes du projet. 
Le chef de projet utilise ses qualites humaines, ou «soft skills »(par exemple, les competences interpersonnelles et la 
capacite a gerer les personnes), pour trouver un equilibre entre les objectifs divergents des parties prenantes et parvenir 
a un consensus. Dans ce contexte, consensus signifie que les parties prenantes concernees soutiennent les decisions 
et les actions du projet meme s’il n’y a pas d’accord total. 

Des recherches montrent que les chefs de projet qui reussissent utilisent certaines competences essentielles de 
maniere constante et efficace. Selon ces recherches, 2 % des meilleurs chefs de projet, tels que designes par leurs 
membres d’equipe et leurs superieurs hierarchiques, se distinguent par leurs excellentes competences de communication 
et de relation, et leur attitude positive [12], 
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La capacite a communiquer avec les parties prenantes, y compris I’equipe et les sponsors, s'applique aux divers 
aspects du projet, notamment: 

♦ I’acquisition de competences pointues a I’aide de plusieurs methodes (par exemple, verbales, ecrites et 
non verbales); 

♦ la creation, la mise a jour et le respect des plans de communication et des echeanciers ; 

♦ une communication previsible et systematique; 

♦ la comprehension des besoins en communication des parties prenantes au projet (La communication peut etre le 
seul livrable regu par certaines parties prenantes avant livraison du service ou du produit fini du projet.); 

♦ la garantie de communications concises, claires, exhaustives, simples, pertinentes et adaptees ; 

♦ I’integration d'informations importantes tant positives que negatives ; 

♦ I’ajout de mecanismes de retour d’information ; 

♦ les competences relationnelles impliquant le developpement de vastes reseaux de personnes dans les spheres 
d'influence du chef de projet. II peut s'agir de reseaux formels, comme les structures hierarchiques de 
I'organisation. Toutefois, les reseaux informels que les chefs de projet developpent, gerent et entretiennent ont 
plus d'importance. Ms incluent les relations etablies avec des personnes comme les specialistes et les dirigeants 
influents. Grace aux reseaux formels et informels, le chef de projet peut faire appel a de multiples personnes pour 
resoudre des problemes et s’orienter au sein des bureaucraties rencontrees dans le cadre d’un projet. 

3.3.3 L’ORGANISATION 

Le chef de projet collabore proactivement avec les autres chefs de projet. Les autres projets independants ou les 
projets qui font partie du meme programme peuvent affecter un projet notamment pour les raisons suivantes : 

♦ les demandes pour les memes ressources ; 

♦ les priorites de financement; 

♦ la reception ou la distribution de livrables; 

♦ I’alignement des huts et des objectifs du projet sur ceux de I'organisation. 

L’interaction avec les autres chefs de projet aide a creer une influence positive pour satisfaire les divers besoins 
du projet. Ces besoins peuvent se presenter sous la forme de ressources humaines, techniques ou financieres et de 
livrables necessaires a I’equipe pour finaliser le projet. Le chef de projet recherche des fagons de developper des 
relations pour aider I’equipe a atteindre les huts et les objectifs du projet. 
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Parallelement, il continue de jouer un role de promotion important au sein de I’organisation. Le chef de projet 
collabore proactivement avec les responsables de I’organisation tout au long du projet. II interagit egalement avec 
le sponsor du projet afin de resoudre les points a traiter en matiere de politique interne ou de strategie susceptibles 
d’affecter soit I’equipe, soit la viabilite ou la qualite du projet. 

Le chef de projet peut s’appliquer a renforcer les competences et les capacites du management de projet dans 
I’organisation et participe aux demarches d’integration ou de transfert des connaissances tacites et explicites (voir 
la section 4.4 sur la gestion des connaissances du projet). II veille egalement a : 

♦ demontrer la valeur du management de projet; 

♦ favoriser I'acceptation du management de projet dans I'organisation ; 

♦ augmenter I'efficacite du bureau des projets, si I'organisation en est dotee. 

Selon la structure organisationnelle, un chef de projet peut dependre hierarchiquement d’un responsable fonctionnel. 
Parfois, un chef de projet peut dependre d’un responsable de bureau des projets ou de portefeuille ou un chef de programme 
qui est, en fin de compte, responsable d’un ou de plusieurs projets pour I’ensemble de I’organisation. II travaille en 
etroite liaison avec tous les dirigeants concernes pour atteindre les objectifs du projet et assurer I’alignement du plan de 
management du projet avec le programme ou le portefeuille. Le chef de projet collabore aussi etroitement avec d’autres 
roles, comme les managers de I'organisation, les specialistes et les personnes qui participent a la business analyse. Dans 
certains cas, le chef de projet peut etre un consultant externe place dans un role de management temporaire. 


3.3.4 LE SECTEUR D’ACTIVITE 

Le chef de projet se tient informe des tendances du secteur d’activite. II tient compte de ces informations et identifie 
leurs impacts ou leurs applications au niveau des projets en cours. Ces tendances comprennent, entre autres : 

♦ le developpement de produit ou de technologie ; 

♦ les nouvelles niches de marche et celles qui evoluent; 

♦ les standards (par exemple, le management de projet, la gestion de la qualite, la gestion de la securite des 
informations); 

♦ les outils de support technique; 

♦ les forces economiques qui impactent le projet immediat; 

♦ les influences sur la discipline du management de projet; 

♦ les strategies d’amelioration et de viabilite des processus. 
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3.3.5 LA DISCIPLINE PROFESSIONNELLE 


Le transfert et I’integration continus des connaissances sont primordiaux pour le chef de projet. Ce developpement 
professionnel est constant dans la profession du management de projet ainsi que dans d’autres domaines oil le chef 
de projet preserve un niveau d’expertise. Le transfert et I’integration des connaissances comprennent, entre autres : 

♦ la contribution des connaissances et de I'expertise a d’autres membres de la profession aux niveaux local, 
national et international (par exemple, les communautes de pratique, les organisations internationales); 

♦ la participation a I’education, a la formation continue et au developpement: 

■ dans la profession du management de projet (par exemple, les universites, le PMI); 

■ dans une profession associee (par exemple, I'ingenierie des systemes, la gestion de la configuration); 

■ dans d'autres professions (par exemple, les technologies de I’information, I'aeronautique). 

3.3.6 LES RELATIONS AVEC D’AUTRES DISCIPLINES 

Un chef de projet professionnel peut choisir d’orienter et d’eduquer d’autres professionnels concernant la valeur 
d’une approche du management de projet dans I’organisation. Le chef de projet peut devenir un ambassadeur informel 
en eduquant I'organisation aux benefices du management de projet en matiere de rapidite, de qualite, d’innovation et 
de gestion des ressources. 


3.4 COMPETENCES DU CHEF DE PROJET 

3.4.1 PRESENTATION 

De recentes etudes du PMI ont applique le Project Management Competency Development (PMCD) Framework aux 
competences necessaires au chef de projet en utilisant le triangle des talents du PMI (Talent Triangle®) illustre a la 
figure 3-2. Ce triangle des talents s’articule autour de trois ensembles de competences cles : 

♦ La technique de management de projet. Connaissances, competences et comportements lies a des domaines 
specifiques du management de projet, programme et portefeuille. Aspects techniques de la realisation de son role. 

♦ Le leadership. Connaissances, competences et comportements necessaires pour guider, motiver et diriger une 
equipe afin d’aider I'organisation a atteindre ses objectifs. 

♦ Le management strategique et organisationnel. Connaissances et expertise dans le secteur et I’organisation 
qui permettent d’ameliorer les performances et d’obtenir de meilleurs resultats. 
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Le PM I Talent Triangle™ 
(Triangle des talents du PMI) 



Management strategique 
et organisationnel 

©Project Management Institute. Tous droits reserves. 



MI*J A I, 


Figure 3-2. Le PMI Talent Triangle™ (Triangle des talents du PMI) 


Si les competences techniques en management de projet sont fondamentales au management de programme et 
de projet, les recherches de PMI indiquent qu'elles ne suffisent pas sur le marche mondial de plus en plus complexe 
et concurrentiel d’aujourd’hui. Les organisations recherchent des competences additionnelles en leadership et en 
intelligence economique. Les membres des diverses organisations affirment que ces competences peuvent realiser les 
objectifs strategies a long terme qui contribuent aux resultats. Pour etre efficaces, les chefs de projet doivent trouver 
un equilibre entre ces trois ensembles de competences. 
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3.4.2 COMPETENCES TECHNIQUES EN MANAGEMENT DE PROJET 


Les competences techniques en management de projet sont definies comme les competences qu’il convient 
d’appliquer efficacement aux connaissances du management de projet afin d’obtenir les resultats souhaites pour les 
programmes ou les projets. II existe de nombreuses competences techniques en management de projet. Les domaines 
de connaissance de ce guide decrivent la plupart de ces competences techniques necessaires en management de 
projet. Les chefs de projet se fient frequemment au jugement a dire d’expert pour etre performants. S’ils souhaitent 
reussir, il est important qu’ils soient conscients de leurs competences personnelles et sachent ou trouver les autres 
personnes ayant I’expertise necessaire. 

Selon les recherches, les meilleurs chefs de projet demontrent constamment plusieurs competences cles, notamment 
une capacite a: 

♦ se concentrer sur les elements techniques critiques du management de projet pour chaque projet gere. II s'agit 
tout simplement d’avoir les bons elements facilement accessibles. Les elements les plus importants comprennent, 
entre autres: 

■ les facteurs critiques de succes du projet; 

■ I’echeancier; 

■ les rapports financiers determines ; 

■ le journal des points a traiter; 

♦ adapter les outils, techniques et methodes traditionnels et agiles pour chaque projet; 

♦ prendre le temps d’effectuer une planification rigoureuse et d’etablir les priorites avec diligence; 

♦ gerer les elements du projet, notamment I’echeancier, les couts, les ressources et les risques. 

3.4.3 COMPETENCES EN MANAGEMENT STRATEGIQUE ET ORGANISATIONNEL 

Les competences en management strategique et organisationnel impliquent la capacite a avoir une vision generale 
de I'organisation, a negocier et appliquer efficacement des decisions et des actions en faveur d’une innovation et 
d’un alignement strategies. Cette capacite peut inclure les connaissances d’autres fonctions, comme la finance, 
le marketing et les operations. Les competences en management strategique et organisationnel peuvent egalement 
inclure le developpement et I’application d’une expertise pertinente liee a un produit ou a un secteur. Ces connaissances 
organisationnelles s'appellent aussi connaissances de domaine. Le chef de projet devrait posseder les connaissances 
necessaires pour pouvoir: 

♦ expliquer les aspects essentiels d’un projet; 

♦ collaborer avec le sponsor, I'equipe et les specialistes du projet afin d’elaborer une strategie appropriee 
d’execution du projet; 

♦ appliquer cette strategie de fagon a optimiser la valeur organisationnelle du projet. 
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En vue de prendre les meilleures decisions quant a la bonne execution de ses projets, le chef de projet devrait 
chercher et tenir compte de I’expertise des responsables des operations charges du management de leur organisation, 
Ces responsables devraient etre au fait du travail realise dans leur organisation et de I’influence qu’auront les plans 
du projet sur ce travail. II est preferable que le chef de projet en sache le plus possible sur le projet. II devrait au moins 
posseder les connaissances necessaires pour expliquer aux autres les aspects suivants de I'organisation : 

♦ la strategie; 

♦ la mission; 

♦ les buts et les objectifs; 

♦ les produits et les services ; 

♦ les operations (par exemple, le lieu, le type, la technologie); 

♦ le marche et sa conjoncture, comme les clients, I’etat du marche (en croissance ou en declin), les facteurs 
d'introduction sur le marche, etc.; 

♦ la concurrence (par exemple, quoi, qui, position sur le marche). 

Le chef de projet devrait appliquer au projet les connaissances et les informations suivantes sur I’organisation afin 
de garantir I'alignement avec : 

♦ la strategie; 

♦ la mission; 

♦ les buts et les objectifs; 

♦ les priorites; 

♦ les tactiques; 

♦ les produits ou services (par exemple, les livrables). 
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Grace a ces competences strategies et organisationnelles, le chef de projet peut definir les facteurs a prendre en 
compte dans le cadre de son projet. II determine les effets que ces facteurs organisationnels et strategies pourraient 
avoir sur le projet tout en comprenant les relations entre le projet et I’organisation. Ces facteurs comprennent, entre autres: 

♦ les risques et les points a traiter; 

♦ les incidences financiers ; 

♦ I’analyse cout-benefice (par exemple, la valeur actuelle nette ou NPV et le retour sur investissement ou ROI), 
y compris les diverses options envisagees ; 

♦ la valeur commerciale; 

♦ les attentes et les strategies en matiere de realisation des benefices; 

♦ le perimetre, le budget, I’echeancier et la qualite. 

Fort de ces connaissances organisationnelles, le chef de projet est habilite a prendre des decisions et de formuler 
des recommandations appropriees pour le projet. Avec revolution du contexte, le chef de projet devrait collaborer 
constamment avec le sponsor du projet afin de maintenir I’alignement des strategies de I'organisation et du projet. 


3.4.4 COMPETENCES EN LEADERSHIP 

Les competences en leadership supposent la capacite a guider, a motiver et a diriger une equipe. Ces competences 
incluent notamment la demonstration de capacites essentielles comme la negotiation, la tenacite, la communication, la 
resolution de problemes, la pensee critique et les competences interpersonnelles. Les projets deviennent de plus en plus 
complexes. En outre, des benefices d’organisation utilisent les projets pour appliquer leurs strategies. Le management 
de projet ne consiste pas seulement a travailler avec des chiffres, des modeles, des tableaux, des graphiques et des 
systemes informatiques. Les personnes sont le denominates commun de tous les projets. Elies ne sont en aucun cas 
des chiffres. 

3.4.4.1 RELATIONS HUMAINES 

Le role du chef de projet consiste en grande partie a traiter avec les collaborateurs. II doit non seulement etudier leurs 
comportements et leurs motivations mais aussi s’efforcer d’etre un bon chef d’equipe, car le leadership est essentiel 
au succes des projets de I’organisation. Le chef de projet applique ses qualites et connaissances en leadership lorsqu’il 
collabore avec toutes les parties prenantes du projet, notamment [’equipe projet, I’equipe de direction et les sponsors 
du projet. 
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3.4.4.2 QUALITES ET COMPETENCES D’UN LEADER 

Selon les recherches, un chef de projet doit avoir notamment les qualites et competences suivantes: 

♦ etre visionnaire (par exemple, aider a decrire les produits, les buts et les objectifs du projet, avoir des reves et 
les traduire pour les autres); 

♦ etre optimiste et positif; 

♦ avoir un esprit de collaboration ; 

♦ gerer les relations et les conflits en : 

■ instaurant un climat de confiance; 

■ repondant aux preoccupations ; 

■ cherchant un consensus ; 

■ trouvant un equilibre entre les objectifs contradictoires ; 

■ appliquant les competences de persuasion, de negociation, de compromis et de resolution des conflits ; 

■ developpant des reseaux personnels et professionnels ; 

■ ayant a I’esprit que sur le long terme les relations sont tout aussi importantes que le projet; 

■ developpant et en appliquant constamment un sens politique ; 

♦ communiquer en : 

■ consacrant suffisamment de temps a cette tache (Les recherches prouvent que les meilleurs chefs de projet 
accordent 90% de leur temps a communiquer sur un projet.); 

■ gerant les attentes ; 

■ accueillant avec bienveillance les commentaires; 

■ faisant des retours constructifs ; 

■ interrogeant et faisant preuve d’ecoute; 

♦ etant respectueux (aider les autres a garder leur autonomie), courtois, aimable, bienveillant, honnete, fiable, 
loyal et ethique; 

♦ faire preuve d’integrite, de conscience culturelle, de courage, de capacite a resoudre les problemes et d’esprit 
de decision; 

♦ reconnaTtre le merite, le cas echeant; 

♦ avoir une capacite d'apprendre tout au long de la vie tout en etant oriente resultats et actions ; 
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♦ se concentrer sur les aspects importants, notamment: 

■ prioriser constamment le travail, passer en revue et ajuster, lorsque c’est necessaire ; 

■ trouver et utiliser une methode pour mettre des priorites, adaptee aux personnes et au projet; 

■ distinguer les priorites strategies de I'organisation, en particulier celles liees aux facteurs critiques de 
succes du projet; 

■ rester vigilant sur les principales contraintes du projet; 

■ faire preuve de souplesse concernant les priorites tactiques; 

■ etre en mesure de passer au crible une quantite importante d’informations afin d’identifier celles qui ont le 
plus d'importance; 

♦ avoir une vision globale et systemique du projet, en prenant en compte de la meme fagon les facteurs internes 
et externes; 

♦ avoir une pensee critique (par exemple, (’application de methodes analytiques pour parvenir a des decisions) et 
s’identifier comme un agent du changement; 

♦ etre capable de constituer des equipes efficaces, etre oriente vers les services, se faire plaisir et rire avec 
les membres de I’equipe. 

3.4.4.3 POLITIQUE, POUVOIR ET PASSAGE A L’ACTION 

Le leadership et le management consistent a etre capable d’obtenir que le travail se fasse. Fort des competences et 
des qualites citees precedemment, le chef de projet est a meme d’atteindre les buts et les objectifs du projet. Un grand 
nombre de ces competences et qualites naissent de la capacite a traiter les questions politiques. La politique necessite 
influence, negotiation, autonomie et pouvoir. 

La politique n’est pas«bonne»ou«mauvaise»,«positive»ou«negative», tout comme ses elements associes. Plus 
le chef de projet comprend le fonctionnement de I'organisation, plus il aura de chances de succes. Le chef de projet 
observe et recueille les donnees sur le projet et ^organisation. Ces donnees doivent ensuite etre passees en revue dans 
le contexte du projet, des personnes concernees, de ^organisation et de I’environnement afin d’obtenir les informations 
et les connaissances necessaires au chef de projet pour planifier et appliquer les actions les plus appropriees. Cette 
action resulte du choix du type de pouvoir requis pour influencer et negocier avec les autres. L'exercice du pouvoir 
s’effectue dans le respect et I'attention dus a autrui. L’efficacite de Taction du chef de projet garantit Tautonomie des 
personnes impliquees. L’action du chef de projet aboutit a Tengagement des bonnes personnes dans les activites 
necessaires a la I’atteinte des objectifs du projet. 
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Le pouvoir peut provenir des caracteristiques propres a la personne ou a I’organisation. II est souvent soutenu par 
la perception que les autres ont du leader. Les chefs de projet doivent absolument etre au fait de la nature de leurs 
liens avec les autres personnes. Ces liens permettent d’obtenir que le travail du projet soit realise. Les chefs de projet 
disposent de nombreuses formes de pouvoir. Le pouvoir, ainsi que son exercice, peut etre complexe selon sa nature et 
les differents facteurs en jeu dans un projet. Parmi les differentes formes de pouvoir, on peut citer: 

♦ le pouvoir de position, parfois appele officiel ou legitime (par exemple, la position officielle conferee au sein de 
I’organisation ou de Tequipe); 

♦ le pouvoir par I’information (par exemple, la maTtrise de la collecte ou de la distribution de I’information); 

♦ le pouvoir de reference (par exemple, le respect ou I’admiration qu’une personne suscite chez autrui, 
la credibilite obtenue); 

♦ le pouvoir situationnel (par exemple, obtenu en raison d’une situation unique comme une crise); 

♦ le pouvoir personnel ou charismatique (par exemple, le charme, I'attraction); 

♦ le pouvoir relationnel (par exemple, la participation au networking, aux relations et aux alliances); 

♦ le pouvoir de I’expert (par exemple, les competences, la possession d'informations, I’experience, la formation, 
I’education, la certification); 

♦ le pouvoir de recompense (par exemple, la capacite a feliciter, a donner une augmentation ou un autre 
element souhaite); 

♦ le pouvoir punitif ou coercitif (par exemple, la capacite a instaurer la discipline ou les consequences negatives); 

♦ le pouvoir de seduction (par exemple, I’usage de flatteries ou d’un terrain d’entente pour obtenir une faveur ou 
une cooperation); 

♦ le pouvoir fonde sur la pression (par exemple, limiter la liberte de choix ou de mouvement dans le but d’adopter 
Taction souhaitee); 

♦ le pouvoir fonde sur la culpabilite (par exemple, imposer une obligation ou le sens du devoir); 

♦ le pouvoir de persuasion (par exemple, la capacite a fournir des arguments pour faire avancer les personnes vers 
le plan d’action souhaite); 

♦ le pouvoir d’evitement (par exemple, le refus de participer). 

Les meilleurs chefs de projet sont proactifs et determines lorsqu’il s’agit de pouvoir. Ms chercheront a acquerir 
le pouvoir et Tautorite necessaires dans les limites des politiques internes, des protocoles et des procedures de 
Torganisation au lieu d’attendre qu’ils leur soient concedes. 
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3.4.5 COMPARAISON ENTRE LEADERSHIP ET GESTION 


Les mots leadership et gestion sont souvent utilises comme synonymes. Pourtant, ils ont un sens different. Le mot 
gestion e st davantage associe a la direction d’une autre personne pour aller d’un point a un autre grace a un ensemble 
connu de comportements attendus. Au contraire, le mot leadership designe la collaboration avec les autres par la 
discussion ou le debat en vue de les guider d’un point a un autre. 

La methode choisie par un chef de projet revele une tres nette difference au niveau du comportement, de la perception 
de soi et du role dans le projet. Le tableau 3-1 compare la gestion et le leadership a differents niveaux importants. 

Pour etre competent, le chef de projet doit faire appel tant au leadership qu'a la gestion. Tout consiste a trouver le 
bon equilibre pour chaque situation. La fagon dont la gestion et le leadership sont utilises se retrouve souvent dans le 
style de leadership du chef de projet. 


Tableau 3-1. Comparaison entre gestion d’equipe et leadership d’equipe 


Management 

Leadership 

Dirige grace au pouvoir positionnel 

Guide, influence etcollabore grace au pouvoir relationnel 

Maintient 

Developpe 

Administre 

Innove 

Cible les systemes et la structure 

Cible les relations avec les personnes 

S’appuie sur le controle 

Inspire la confiance 

Cible les objectifs a court terme 

Cible une vision a long terme 

Demande comment et quand 

Demande quoi et pourquoi 

Cible le benefice net 

Cible I'horizon 

Accepte le status quo 

Conteste le status quo 

Fait bien les choses 

Fait les bonnes choses 

Cible les point a traiter sur le plan operationnel 
et la resolution des problemes 

Cible la vision, I'harmonisation, la motivation 
et I’inspiration 
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3.4.5.1 STYLES DE LEADERSHIP 


Le chef de projet peut diriger son equipe de differentes fagons. II peut choisir son style sur la base d’une preference 
personnel^ ou du resultat de la combinaison de plusieurs facteurs associes au projet. Le style d’un chef de projet peut 
changer avec le temps en fonction des facteurs en jeu. Ces facteurs majeurs a prendre en compte comprennent, entre autres: 

♦ les caracteristiques du leader (par exemple, les attitudes, les humeurs, les besoins, les valeurs, I’ethique); 

♦ les caracteristiques des membres de I'equipe (par exemple, les attitudes, les humeurs, les besoins, les 
valeurs, I’ethique); 

♦ les caracteristiques de I’organisation (par exemple, sa finalite, sa structure et le type de travail effectue); 

♦ les caracteristiques de I’environnement (par exemple, la situation sociale, I’etat economique et les elements politiques). 

Les recherches decrivent de nombreux styles de leadership que le chef de projet peut adopter. Parmi les exemples 
les plus courants de ces styles figurent notamment: 

♦ le style«laissez-faire»(par exemple, laisser I’equipe prendre ses decisions et etablir ses buts, egalement appele 
le style non interventionniste); 

♦ le style transactionnel (par exemple, concentration sur la realisation des objectifs, le retour d’information et 
I'accomplissement en echange de recompenses, gestion par exception); 

♦ le style leader-serviteur (par exemple, demonstration de I'engagement a servir et faire passer les autres en 
premier, concentration sur le developpement, I'apprentissage, I’autonomie et le bien-etre des autres, sur les 
relations, la communaute et la collaboration ; le leadership est secondaire et emerge apres le service); 

♦ le style transformationnel (par exemple, responsabilisation des personnes par des attributs et des comportements 
idealises, motivation inspiree, incitation a I’innovation et a la creation, consideration de la personne); 

♦ le style charismatique (par exemple, capacite a inspirer, grande energie, enthousiasme, confiance en soi, 
convictions fortes); 

♦ le style interactionnel (par exemple, une combinaison des styles transactionnel, transformationnel 
et charismatique). 
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3.4.5.2 PERSONNALITE 

Le mot personnalite designe les differences individuelles dans les schemas cognitifs, emotionnels et comportementaux 
caracteristiques. Parmi les caracteristiques ou traits de personnalite, on peut citer: 

♦ I'authenticite (par exemple, accepter les autres tels qu’ils sont, manifester un interet sincere); 

♦ la courtoisie (par exemple, capacite a adopter un bon comportement); 

♦ la creativite (par exemple, capacite a penser de fagon abstraite, a voir les choses differemment, a innover); 

♦ la conscience a la culture (par exemple, mesurer la conscience des autres cultures, notamment les valeurs, les 
normes et les croyances); 

♦ I'empathie (par exemple, capacite a percevoir les emotions et les informations qu’elles presentent et a les gerer, 
mesurer les competences interpersonnelles); 

♦ I’intellect (par exemple, mesurer I'intelligence humaine sur plusieurs aptitudes); 

♦ le managerial (par exemple, mesurer le potentiel et la pratique du management); 

♦ le politique (par exemple, mesurer I'intelligence politique etfaire que les choses avancent); 

♦ I’orientation vers les services (par exemple, preuve de la volonte a servir autrui); 

♦ la sociability (par exemple, capacite a comprendre et a gerer les personnes); 

♦ la systemique (par exemple, volonte de connartre et a batir des systemes). 

Pour reussir, un chef de projet aura un certain niveau de capacite avec toutes ces caracteristiques. Pour chaque 
projet, organisation et situation, le chef de projet doit mettre I’accent sur differents aspects de la personnalite. 


3.5 INTEGRATION 

Le chef de projet a un double role a jouer lors de (’integration dans le cadre du projet. 

♦ Le chef de projet joue un role cle dans sa collaboration avec le sponsor du projet afin de comprendre les objectifs 
strategies et de garantir Palignement des objectifs et des resultats du projet sur ceux du portefeuille, du 
programme et de I’organisation. Ainsi, il contribue a (’integration et a I'execution de la strategic. 

♦ Le chef de projet est charge d’orienter I'equipe afin de travailler ensemble et de se concentrer sur Pessentiel. 
Pour ce faire, il doit integrer les processus, les connaissances et les personnes. 

Integration est une competence fondamentale du chef de projet. Elle est traitee plus en detail dans le domaine 
de connaissance dedie a la gestion de (’integration du projet de ce guide. Les sections 3.5.1 a 3.5.4 sont axees sur 
(’integration qui a lieu a trois niveaux differents : le niveau du processus, le niveau cognitif et le niveau du contexte. 
La section 3.5.4 termine en abordant la complexity et (’integration. 
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3.5.1 INTEGRATION AU NIVEAU DU PROCESSUS 


Le management de projet peut etre pergu comme un ensemble de processus et d’activites entrepris pour atteindre 
les objectifs du projet. Certains de ces processus peuvent avoir lieu une seule fois (par exemple, la creation initiale de la 
charte du projet). Cependant, la plupart des processus se chevauchent ou interviennent plusieurs fois durant le projet. Par 
exemple, le changement d’une exigence ayant un impact sur le perimetre, I’echeancier ou le budget et necessitant une 
demande de changement. Plusieurs processus de management de projet, tels que les processus MaTtriser le perimetre 
et MaTtriser les changements, peuvent inclure une demande de changement. Le processus MaTtriser les changements 
permet d’integrer les demandes de changement. 

Si (’integration des processus du projet n’est pas definie dans I'organisation, et si le chef de projet ne parvient pas 
a integrer les processus du projet au niveau de leurs interactions, le projet a peu de chances d'atteindre ses objectifs. 


3.5.2 INTEGRATION AU NIVEAU COGNITIF 

II existe de nombreusesfagons de manager un projet. En regie generate, la methode choisie depend des caracteristiques 
particulieres du projet, notamment de sa taille, du niveau de complexity du projet ou de I'organisation et de sa culture. 
La fagon dont le projet est manage est intimement liee aux competences personnels du chef de projet. 

Le chef de projet doit s’efforcer a devenir competent dans tous les domaines de connaissance du management 
de projet. Parallelement a la martrise de ces domaines de connaissance, le chef de projet utilise son experience, sa 
perspicacity, son leadership et ses competences en gestion technique et organisationnelle dans le cadre du projet. 
Enfin, grace a la capacity du chef de projet a integrer les processus dans ces domaines de connaissance, il est possible 
d’obtenir les resultats souhaites du projet. 


3.5.3 INTEGRATION AU NIVEAU DU CONTEXTE 

Le contexte dans lequel les activites organisationnelles et les projets ont lieu aujourd’hui a beaucoup change depuis 
quelques decennies. De nouvelles technologies ont ete introduites. Les reseaux sociaux, les aspects multiculturels, 
les equipes virtuelles et les nouvelles valeurs font partie de la nouvelle realite des projets. II s’agit, par exemple, 
de I’integration des connaissances et des personnes dans le contexte de I'application d’un grand projet transversal 
impliquant plusieurs organisations. Le chef de projet examine les implications de ce contexte dans la planification 
des communications et la gestion des connaissances afin d’orienter I’equipe projet. 

II doit connaTtre le contexte du projet et ces nouveaux aspects lors de la gestion de I'integration. Ensuite, il peut decider 
de I’utilisation optimale de ces nouveaux elements dans I’environnement de ses projets afin de garantir leur succes. 


67 



3.5.4 INTEGRATION ET COMPLEXITY 


Certains projets peuvent etre qualifies de complexes et difficiles a manager. Complexe et complique sont des concepts 
souvent utilises pour decrire ce qui est considere comme elabore ou difficile. 

La complexity des projets resulte du comportement du systeme, du comportement humain et de I’incertitude au 
travail au sein de I'organisation ou de son environnement. Le document Navigating Complexity: A Practice Guide [13] 
definit ces trois dimensions de complexity comme : 

♦ Comportement du systeme. Les interdependences des composants et des systemes. 

♦ Comportement humain. L'interaction entre les personnes et les groupes. 

♦ Ambigu'ite. L’incertitude quant a I’emergence de problemes et le manque de comprehension ou la confusion. 

La complexity est une perception d’une personne fondee sur I’experience, I’observation et les competences 
personnels. Un projet n'est pas complexe, mais est davantage decrit comme comportant de la complexity. Les 
portefeuilles, les programmes et les projets peuvent contenir des elements de complexity. 

Lorsque le chef de projet aborde I’integration d’un projet, il devrait tenir compte des elements qui sont internes 
comme externes au projet. Le chef de projet devrait examiner les caracteristiques ou les proprietes du projet. La 
complexity, en tant que caracteristique ou propriety d’un projet, est generalement definie comme : 

♦ comportant plusieurs parties; 

♦ possedant de nombreuses connexions entre les parties ; 

♦ presentant des interactions dynamiques entre les parties; 

♦ ayant un comportement issu de ces interactions qui ne peuvent pas etre expliquees comme la simple somme des 
parties (par exemple, un comportement emergent). 

L’analyse de ces elements qui semblent complexifier le projet devrait aider le chef de projet a identifier les principaux 
domaines lors de la planification et de la maTtrise du projet en vue de I’integration. 
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GESTION DE (.’INTEGRATION DU PROJET 

La gestion de I’integration du projet inclut les processus et les activites qui identifient, definissent, combinent, unifient 
et coordonnent les differents processus et activites de management de projet au sein des groupes de processus de 
management du projet. Dans le contexte du management de projet, I’integration inclut des caracteristiques d’unification, 
de consolidation, de communication et d'interaction. Ces actions doivent etre executees du debut a la fin du projet. 
La gestion de I’integration du projet implique de faire des choix dans les domaines suivants: 

♦ I’allocation des ressources ; 

♦ I’equilibre entre des contraintes divergentes ; 

♦ I’examen d’approches alternatives ; 

♦ I’adaptation des processus pour atteindre les objectifs du projet; 

♦ la gestion des interdependences entre les domaines de connaissance en management de projet. 
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Les processus de gestion de I’integration du projet sont les suivants : 

4.1 Elaborer la charte du projet —Ce processus consiste a elaborer un document qui autorise formellement I’existence 
d’un projet et donne au chef de projet le droit d’allouer des ressources de I'organisation aux activites de ce projet. 

4.2 Elaborer le plan de management du projet —Ce processus consiste a definir, preparer et coordonner tous les 
elements du plan, et les integrer dans un plan complet de management du projet. 

4.3 Diriger et gerer le travail du projet —Ce processus consiste a diriger et realiser le travail defini dans le plan de 
management du projet et appliquer les changements approuves pour atteindre les objectifs du projet. 

4.4 Gerer les connaissances du projet —Ce processus consiste a utiliser les connaissances existantes et a en 
acquerir de nouvelles pour atteindre les objectifs du projet et contribuer a I’apprentissage organisationnel. 

4.5 Maitriser le travail du projet —Ce processus consiste a suivre, passer en revue et communiquer I’avancement 
global par rapport aux objectifs de performance definis dans le plan de management du projet. 

4.6 Maitriser les changements —Ce processus consiste a passer en revue toutes les demandes de changement, 
puis approuver et gerer les changements apportes aux livrables, aux actifs organisationnels, aux documents et au plan 
de management du projet, puis communiquer les decisions. 

4.7 Clore le projet ou la phase —Ce processus consiste a finaliser toutes les activites d’un projet, d’une phase ou 
d’un contrat. 

La figure 4-1 donne une vue d’ensemble des processus de gestion de I’integration du projet. Les processus de 
gestion de I’integration du projet sont presentes comme des processus distincts aux interfaces clairement definies 
tandis que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre 
completement detaillees dans le Guide PMBOK®. 
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Vue d’ensemble de la gestion 
de l’integration du projet 


4.1 Elaborer la charte 
du projet 


.1 Donnees d'entree 
.1 Documents business 
.2 Accords 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils et techniques 
.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Competences 
interpersonnelles 
et d'equipe 
.4 Reunions 

.3 Donnees de sortie 

.1 Elaborer la charte du projet 
.2 Journal des hypotheses 


4.S Maitriser 
le projet 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Information sur 
la performance d'execution 
.4 Accords 
.5 Facteurs 
environnementaux 
de I'organisation 
.6 Actifs organisationnels 

.2 Outils et techniques 
.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Prise de decision 
.4 Reunions 

.3 Donnees de sortie 
.1 Rapports sur 
la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour 
des documents du projet 

v___y 


4.2 Elaborer le plan 
de management du projet 


.1 Donnees d'entree 
.1 Elaborer la charte 
du projet 

.2 Donnees de sortie 
d'autres processus 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Competences 
interpersonnelles 
et d'equipe 
.4 Reunions 

.3 Donnees de sortie 
.1 Elaborer le plan 
de management du projet 

V___/ 


4.6 Maitriser 
les changements 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Rapports sur 
la performance d'execution 
.4 Demandes de changement 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 

.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Outils de gestion 
des changements 
.3 Analyse des donnees 
.4 Prise de decision 
.5 Reunions 

.3 Donnees de sortie 
.1 Demandes de changement 
approuvees 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

v _/ 


4.3 Diriger et gerer 
le travail du projet 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Demandes de changement 
approuvees 
.4 Facteurs 
environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Systeme d’information 
de gestion du projet 
(Project Management 
Information System, PMIS) 

.3 Reunions 

.3 Donnees de sortie 
.1 Livrables 

.2 Donnees de performance 
d'execution 

.3 Journal des points a traiter 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour 
des documents du projet 
.7 Mises a jour des actifs 
organisationnels 

v___/ 


4.7 Clore le projet 
ou la phase 


.1 Donnees d'entree 
.1 Elaborer la charte du projet 
.2 Elaborer le plan 
de management du projet 
.3 Documents du projet 
.4 Livrables acceptes 
.5 Documents business 
.6 Accords 
.7 Documents 
d'approvisionnements 
.8 Actifs organisationnels 

.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Reunions 

.3 Donnees de sortie 
.1 Mises a jour 
des documents du projet 
.2 Transfert du produit, 
du service ou du resultat 
final 

.3 Rapport final 
.4 Mises a jour des actifs 
organisationnels 


4.4 Gererles 
connaissances du projet 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Livrables 
.4 Facteurs 
environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Gestion 
des connaissances 
.3 Gestion de I'information 
.4 Competences 
interpersonnelles 
et d'equipe 

.3 Donnees de sortie 
.1 Registre des retours 
d'experience 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des actifs 
organisationnels 


Figure 4-1. Vue d’ensemble de la gestion de (’integration du projet 
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PRINCIPAUX CONCEPTS DE LA GESTION DE L’INTEGRATION DU PROJET 

La gestion de I’integration du projet est propre aux chefs de projets. Si d’autres domaines de connaissance peuvent 
etre geres par des specialistes ((’analyse des couts, la planification, la gestion des risques), la responsabilite de la 
gestion de I’integration du projet ne peut etre deleguee ni transferee. Le chef de projet est celui qui combine les resultats 
dans tous les autres domaines de connaissance et possede une vue d’ensemble du projet. En fin de compte, il est 
responsable du projet dans son ensemble. 

Les projets et le management de projet sont integrates par nature. Par exemple, une estimation de cout requise pour 
un plan de contingence implique I’integration des processus dans les domaines de connaissance suivants : gestion des 
couts, gestion de I'echeancier et gestion des risques du projet. Lorsque des risques supplementaires lies aux diverses 
options d’affectation des ressources humaines sont identifies, un ou plusieurs de ces processus pourraient etre revus. 

Les liens entre les processus de management de projet sont souvent de nature iterative. Par exemple, des un stade 
precoce du projet, le groupe de processus de planification fournit au groupe de processus d’execution, un plan de 
management du projet documents qui est ensuite mis a jour dans le cas ou des changements surviendraient au fur et 
a mesure que le projet avance. 

La gestion de I’integration du projet consiste a: 

♦ veiller a ce que les echeances des livrables du produit, service ou resultat, le cycle de vie du projet et le plan 
de gestion des benefices soient alignes ; 

♦ fournir un plan de management du projet pour atteindre les objectifs du projet; 

♦ garantir la creation et I’utilisation des connaissances appropriees dans le cadre du projet; 

♦ gerer les performances et les changements des activites dans le plan de management du projet; 

♦ prendre des decisions coherentes concernant les principaux changements impactant le projet; 

♦ mesurer et maTtriser I’avancement du projet et entreprendre toute action appropriee en vue d’atteindre les 
objectifs du projet; 

♦ recueillir les donnees sur les resultats obtenus, analyser les donnees pour obtenir des informations et 
communiquer ces informations aux parties prenantes concernees ; 

♦ executer tout le travail du projet et clore formellement chaque phase, chaque contrat et le projet dans son ensemble; 

♦ gerer, au besoin, les transitions entre les phases. 

Plus le projet est complexe et plus les attentes des parties prenantes sont diverses, plus la methode d’integration 
doit etre sophistiquee. 
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TENDANCES ET PRATIQUES EMERGENTES EN GESTION DE ^INTEGRATION DU PROJET 


Le domaine de connaissance lie a la gestion de I’integration du projet necessite de combiner les resultats de tous les 
autres domaines de connaissance. Les nouvelles tendances des processus d'integration comprennent notamment les 
elements suivants: 

♦ Utilisation d’outils automatises. Le volume de donnees et d’informations que les chefs de projets doivent 
integrer necessite souvent I’utilisation d’un systeme d'information de management du projet (PMIS) et des outils 
automatises pour recueillir, analyser et utiliser les informations en vue d’atteindre les objectifs du projet et 
d’obtenir des benefices. 

♦ Utilisation d’outils visuels de management. Pour saisir et superviser les elements essentiels du projet, 
certaines equipes projet utilisent des outils visuels de management plutot que des plans et d'autres documents 
ecrits. La visualisation des principaux elements du projet par I'equipe tout entiere offre un apergu en temps reel 
de I’etat du projet, facilite le transfert de connaissances et permet aux membres de I’equipe et aux autres parties 
prenantes d’identifier et de resoudre les points a traiter. 

♦ Gestion des connaissances du projet. La main-d’oeuvre, de plus en plus mobile et temporaire, necessite un 
processus plus rigoureux pour identifier les connaissances tout au long du cycle de vie du projet et les transferer, 
sans perte, aux parties prenantes cibles. 

♦ Expansion des responsabilites du chef de projet. Les chefs de projets sont appeles a lancer et a finaliser 
le projet, notamment a elaborer le business case du projet et a en gerer les benefices. Habituellement, ces 
activites relevent de la responsabilite de la direction et du project management office (PMO); mais les chefs de 
projets collaborent frequemment avec eux pour mieux atteindre les objectifs du projet et livrer les benefices. Les 
chefs de projets s'engagent egalement a identifier et engager les parties prenantes. Cela suppose de gerer les 
interfaces avec les differents services operationnels etfonctionnels etavec le personnel de la direction generate. 

♦ Methodologies hybrides. Certaines methodologies de management de projet evoluent afin d'integrer les 
nouvelles pratiques appliquees avec succes. II s’agit notamment d’utiliser des pratiques agiles et d’autres 
pratiques iteratives, des techniques de Business Analysis pour la gestion des exigences, des outils permettant 
d’identifier des elements de projet complexes et des methodes de gestion des changements organisationnels, 
visant a preparer I’integration des donnees de sortie du projet au sein de I'organisation. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 


Chaque projet etant unique, le chef de projet devra adapter ('application des processus de gestion de (’integration. 
Parmi les considerations relatives a ('adaptation, on peut citer les elements suivants: 

♦ Cycle de vie du projet. Qu’est-ce qu’un cycle de vie approprie au projet ? Quelles phases doivent composer le 
cycle de vie du projet ? 

♦ Cycle de vie de developpement. Quel cycle de vie et quelle approche de developpement sont appropries pour le 
produit, le service ou le resultat ? L'approche appropriee est-elle plutot predictive ou adaptative ? Dans ce cas, le 
produit doit-il etre developpe de maniere incrementielle ou iterative ? Une approche hybride est-elle meilleure ? 

♦ Approches de gestion. Quels sont les processus de gestion les plus efficaces au vu de la culture organisationnelle 
et de la complexity du projet ? 

♦ Gestion des connaissances. Comment seront gerees les connaissances dans le cadre des projets afin de 
favoriser un environnement de travail collaboratif ? 

♦ Changement. Comment sera gere le changement dans le cadre du projet ? 

♦ Gouvernance. Quels comites de pilotage, autres comites et parties prenantes font partie du projet ? Quelles sont 
les exigences en matiere de communication de I'etat du projet ? 

♦ Retours d’experience. Quelles informations doivent etre recueillies tout au long et a la fin du projet ? Comment 
les donnees historiques et le retour d’experience pourront-ils beneficier aux projets futurs ? 

♦ Benefices. Quand et comment les benefices doivent-ils etre communiques : a la fin du projet ou a la fin de 
chaque iteration ou phase ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les approches iteratives et agiles encouragent I’engagement des membres de I'equipe en tant que specialistes de 
la gestion de (’integration au niveau local. Les membres de I’equipe determined comment les plans et les elements 
doivent etre integres. 

Les attentes du chef de projet telles qu’indiquees dans les principaux concepts de la gestion de /’integration restent les 
memes dans un environnement adaptatif, mais la maTtrise de la planification detaillee et de la livraison des produits est 
deleguee a I'equipe. Le chef de projet concentre ses efforts sur la creation d’un environnement decisionnel collaboratif 
et s’assure que I’equipe est capable de reagir aux changements. Cette approche collaborative peut etre renforcee 
lorsque les membres de I’equipe possedent de vastes competences et non pas une specialisation particuliere. 
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4.1 ELABORER LA CHARTE DU PROJET 


Elaborer la charte du projet est le processus consistant a developper un document qui autorise formellement 
I’existence d’un projet et donne autorite au chef de projet pour allouer des ressources de I’organisation aux activites 
de ce projet. L'interet principal de ce processus est d’offrir un lien direct entre le projet et les objectifs strategies 
de I'organisation, cree une identification formelle du projet et montre I'engagement de I’organisation dans le cadre du 
projet. Ce processus est execute au moins une fois ou a plusieurs moments predefinis durant le projet. Les donnees 
d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la figure 4-2. La 
figure 4-3 represente le diagramme de flux de donnees du processus. 




.1 Documents business 


.1 Jugement a dire d'expert 


.1 Elaborer la charte du projet 
.2 Journal des hypotheses 


• Business case 

• Plan de gestion 


.2 Collecte des donnees 

• Brainstorming 

• Groupes de discussion 

• Entretiens 


J 


des benefices 
.2 Accords 


.4 Actifs organisationnels 


.3 Facteurs environnementaux 


de I'organisation 


.3 Competences 

interpersonnelles et d'equipe 
• Gestion des conflit 


V. 


J • Facilitation 


• Gestion des reunion 
.4 Reunions 

V_ 


Figure 4-2. Elaborer la charte du projet: donnees d’entree, outils, techniques et donnees de sortie 


75 















Figure 4-3. Elaborer la charte du projet: diagramme de flux de donnees 
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La charte du projet etablit un partenariat entre I'organisation realisatrice et celle qui a initie la demande. Dans le cas 
de projets externalises, habituellement, un contrat formalise I’accord. Une charte de projet peut encore etre utilisee pour 
etablir les accords internes au sein des organisations impliquees, afin d’assurer une livraison conforme aux termes du 
contrat. La charte du projet, une fois approuvee, initialise formellement le projet. Un chef de projet doit etre identifie 
et assigne des que possible, de preference lors de ('elaboration de la charte du projet, et toujours avant le debut de la 
planification. La charte du projet peut etre elaboree par le sponsor ou le chef de projet en collaboration avec I'entite 
initiatrice. Cette collaboration permet au chef de projet de mieux comprendre I'objet, les objectifs et les benefices 
attendus du projet. Cette comprehension permettra une allocation efficiente des ressources aux activites du projet. La 
charte du projet donne au chef de projet le droit de planifier, d'executer et de maitriser le projet. 

Les projets sont initialises par une entite externe au projet, comme un sponsor, un membre du bureau des projets ou 
du bureau des programmes (Program or Project Management Office ou PMO), un responsable du comite de gouvernance 
de portefeuille ou bien encore un representant autorise. Le niveau d’autorite de I’initiateur du projet ou du sponsor doit 
permettre de garantir le financement approprie et d’engager des ressources pour le projet. Les projets sont demarres 
parce qu’ils repondenta des besoins internes ou a des influences externes. Ces besoins ou ces influences declenchent 
souvent le lancement d’une analyse des besoins, d’une etude de faisabilite, d’un business case ou une description de 
la situation a laquelle le projet repondra. L'elaboration de la charte d’un projet valide I'alignement du projet avec la 
strategie et les activites courantes de I'organisation. Une charte de projet n’est pas un contrat a proprement parler, car 
sa creation ne donne pas lieu a I'echange ou a la promesse d’une quelconque contrepartie ou somme d’argent. 


4.1.1 ELABORER LA CHARTE DU PROJET : DONNEES D’ENTREE 

4.1.1.1 DOCUMENTS BUSINESS 

Le business case (decrit a la section 1.2.6.1) et le plan de gestion des benefices (decrit a la section 1.2.6.2) sont des 
sources d'information sur les objectifs du projet et la fagon dont le projet contribuera aux objectifs de la societe. Bien 
que les documents business soient elabores avant le projet, ils sont revus regulierement. 

♦ Business case. Le business case approuve, ou un document similaire, est la source la plus couramment utilisee 
pour creer la charte du projet. II presente les informations necessaires permettant de determiner, du point de vue 
du business, si les resultats attendus justifient I’investissement requis par le projet. II est habituellement utilise 
par les gestionnaires ou les cadres dirigeants pour prendre des decisions. Afin de justifier le projet et d’en etablir 
les limites, le business case comprend generalement les besoins du business et une analyse cout-benefice. Pour 
obtenir de plus amples informations sur le business case, voir la section 1.2.6.1. Ce business case est construit 
a partir d’un ou de plusieurs des points suivants: 
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■ une demande du marche (par exemple, un constructeur automobile autorisant, face a une penurie 
d’essence, le projet de construction d’un plus grand nombre de voitures peu gourmandes en carburant); 

■ un besoin organisationnel (une societe peut, par exemple, en raison de frais eleves, optimiser 
I’organisation de son personnel et alleger les processus pour reduire les couts); 

■ une demande de clients (par exemple, une compagnie d’electricite autorisant le projet de construction 
d’une nouvelle sous-station pour desservir un nouveau pare industriel); 

■ une avancee technologique (une compagnie aerienne peut, par exemple, sur la base d’avancees 
technologiques, autoriser un nouveau projet visant a developper des billets electroniques pour remplacer 
les billets papier); 

■ une exigence legale (par exemple, un fabricant de peinture autorisant un projet d’elaboration 
d’instructions pour la manipulation de produits toxiques); 

■ un impact ecologique (par exemple, une societe autorisant un projet de reduction de son impact 
environnemental); 

■ un besoin social (par exemple, une organisation non gouvernementale qui, dans un pays en voie de 
developpement, autorise un projet fournissant des systemes d’alimentation en eau potable, des toilettes 
publiques et une education sanitaire aux communautes affectees par des taux eleves de cholera). 

La charte du projet integre les informations appropriees pour le projet a partir des documents business. Le chef de 
projet ne revise ni ne modifie les documents business, car ce ne sont pas des documents de projet. II peut neanmoins 
faire des recommandations. 

4.1.1.2 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les accords sont utilises pour definir les intentions initiales qui sous-tendent 
un projet. Les accords peuvent revetir la forme de contrats, de protocoles d'accord, d’accords de niveaux de service 
(SLA), de lettres d’accord, de lettres d'intention, d’accords verbaux, de courriers electroniques ou de toute autre forme 
d'accord ecrit. Un contrat est generalement utilise lorsqu’un projet est realise pour un client externe. 

4.1.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Elaborer la 
charte du projet, on peut citer: 

♦ les standards gouvernementaux ou industriels (standards de produits, standards de qualite, standards de securite 
et standards de fabrication); 

♦ les exigences et/ou contraintes reglementaires et juridiques ; 

♦ les conditions du marche ; 

♦ la culture organisationnelle et le climat politique ; 

♦ le cadre de gouvernance organisationnelle (un moyen structure de procurer maTtrise, orientation et coordination 
grace a des personnes, des politiques et des processus, en vue d’atteindre des objectifs organisationnels 
strategies et operationnels); 

♦ les attentes des parties prenantes et les seuils de risque. 
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4.1.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Elaborer la charte du projet, on 
peut citer: 

♦ les politiques, processus et procedures standardises de I'organisation ; 

♦ le cadre de gouvernance du portefeuille, du programme et du projet (fonctions et processus de gouvernance pour 
fournir des conseils et prendre des decisions); 

♦ les methodes de maitrise et de communication ; 

♦ les modeles (par exemple, un modele de charte de projet); 

♦ les donnees historiques et I’archive des retours d’experience (par exemple, des enregistrements et des 
documents du projet, des informations relatives aux resultats des decisions de selection de projets anterieurs et 
aux performances de projets anterieurs). 

4.1.2 ELABORER LA CHARTE DU PROJET : OUTILS ET TECHNIQUES 
4.1.2.1 JUGEMENTA DIRE D’EXPERT 

Le Jugement a dire d’expert designe un avis emis en vertu d’une expertise dans un champ d’application, un domaine 
de connaissance, une discipline ou un secteur d’activite, cette expertise s’averantappropriee quanta I'activite effectuee. 
Une telle expertise peut etre fournie par un groupe ou une personne ayant suivi des etudes adequates et possedant une 
connaissance, une competence, une experience ou une formation professionnelle specialisee. 

Pour ce processus, il convient de faire appel a la competence de personnes ou de groupes ayant une connaissance 
specialisee ou une formation dans les domaines suivants: 

♦ strategie organisationnelle; 

♦ gestion des benefices ; 

♦ connaissances techniques du secteur d’activite et du domaine d’interet specifique du projet; 

♦ estimation de duree et budgetaire; 

♦ identification des risques. 
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4.1.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Brainstorming. Cette technique est utilisee pour repertorier une liste d'idees en peu de temps. II est organise 
dans un environnement de groupe sous la conduite d’un animateur. II comprend deux parties : la generation 
d’idees et I’analyse. Le brainstorming peut etre utilise pour collecter les donnees, les solutions ou les idees des 
parties prenantes, des specialistes et des membres de I’equipe au cours de (’elaboration de la charte du projet. 

♦ Groupes de discussion. Ms sont decrits a la section 5.2.2.2. Les groupes de discussion reunissent les parties 
prenantes et les specialistes dans le but de definir la perception du risque sur le projet, les criteres de reussite et 
d’autres themes de fagon plus conversationnelle qu’un entretien individuel. 

♦ Entretiens. Ms sont decrits a la section 5.2.2.2. Les entretiens sont utilises pour obtenir des informations sur les 
exigences de haut niveau, les hypotheses, les contraintes, les criteres d'approbation et d’autres informations 
aupres des parties prenantes en parlant directement avec elles. 

4.1.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Gestion des conflits. Elle est decrite a la section 9.5.2.1. La gestion des conflits peut etre utilisee pour aider 
les parties prenantes a s’orienter vers les objectifs, les criteres de reussite, les exigences de haut niveau, la 
description du projet, les jalons recapitulates et les autres elements de la charte. 

♦ Facilitation. La facilitation designe la capacite a diriger un evenement de groupe vers une decision, une solution 
ou une conclusion efficace. Un animateur veille a la bonne participation, a ce que les participants se comprennent 
mutuellement, a ce que toutes les contributions soient prises en compte, a ce que les conclusions ou les resultats 
emportent une adhesion totale, conformement au processus decisionnel etabli pour le projet, et a ce que les 
mesures et les accords obtenus soient correctement traites par la suite. 

♦ Gestion des reunions. Elle est decrite a la section 10.2.2.6. La gestion des reunions implique de preparer I’ordre 
du jour, de s’assurer qu’un representant de chaque groupe de parties prenantes est invite et d’elaborer puis 
d’envoyer le compte-rendu et les actions de suivi. 

4.1.2.4 REUNIONS 

Pour ce processus, des reunions sont organisees avec les parties prenantes afin d’identifier les objectifs du 
projet, les criteres de reussite, les principaux livrables, les exigences de haut niveau, les jalons recapitulates ettoute 
autre information. 
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4.1.3 ELABORER LA CHARTE DU PROJET : DONNEES DE SORTIE 


4.1.3.1 CHARTE DU PROJET 

La charte du projet est le document emis par I’initiateur du projet, ou par son sponsor, qui autorise formellement 
I'existence du projet et donne autorite au chef de projet pour allouer des ressources de I'organisation aux activites du 
projet. Elle documente les informations de haut niveau concernant le projet mais aussi le produit, le service ou le resultat 
que le projet doit satisfaire, telles que : 

♦ I’objet du projet; 

♦ les objectifs mesurables du projet et les criteres de reussite correspondants; 

♦ les exigences de haut niveau ; 

♦ la description du projet, les limites et les principaux livrables ; 

♦ le risque global du projet; 

♦ un echeancier a jalons recapitulate; 

♦ les ressources financiers preapprouvees; 

♦ la liste des principales parties prenantes ; 

♦ les exigences d’acceptation du projet (c’est-a-dire, ce qui definit la reussite du projet, la personne qui decide que 
le projet est reussi et celle qui valide le projet); 

♦ les criteres de sortie du projet (c’est-a-dire les conditions a respecter afin de clore ou d’annuler le projet ou la phase); 

♦ le chef de projet designe, sa responsabilite et son niveau d'autorite; 

♦ le nom et le niveau d'autorite du sponsor ou des autres personnes qui autorisent la charte du projet. 

A un niveau superieur, la charte du projet permet aux parties prenantes de bien comprendre les principaux livrables, 
les jalons, ainsi que les roles et les responsabilites de chaque personne participant au projet. 

4.1.3.2 JOURNAL DES HYPOTHESES 

Les hypotheses et les contraintes operationnelles et strategies de haut niveau sont normalement recensees dans 
le business case avant le debut du projet et seront transferees dans la charte du projet. Des hypotheses de taches et 
d’activites de niveau inferieur sont generees tout au long du projet, comme la definition des caracteristiques techniques, 
des estimations, de I’echeancier et des risques. Le journal des hypotheses est utilise pour conserver I’ensemble des 
hypotheses et des contraintes tout au long du cycle de vie du projet. 
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4.2 ELABORER LE PLAN DE MANAGEMENT DU PROJET 


L’elaboration du plan de management du projet est le processus consistant a definir, a preparer et a coordonner 
tous les composants du plan, et a les integrer dans un plan complet de management du projet. L’interet principal de ce 
processus est de produire un document complet qui definit la base de tout le travail du projet et la fagon dont le travail 
sera accompli. Ce processus est execute au moins une fois ou a plusieurs moments predefinis durant le projet. Les 
donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la figure 4-4. 
La figure 4-5 represente le diagramme de flux de donnees du processus. 


Elaborer le plan de management du projet 


Donnees d’entree 


.1 Elaborer la charte du projet 
.2 Donnees de sortie d'autres 
processus 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

v___y 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Collecte des donnees 

• Brainstorming 

• Checklists 

• Groupes de discussion 

• Entretiens 

.3 Competences 

interpersonnelles et d'equipe 
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Figure 4-4. Elaborer le plan de management du projet: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 4-5. Elaborer le plan de management du projet: diagramme de flux de donnees 
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Le plan de management du projet definit la fagon dont le projet sera execute et martrise, puis clos. Le contenu du plan 
de management du projet depend du champ d’application du projet et de sa complexite. 

Le plan de management du projet peut etre plus ou moins detaille. Le plan de chaque element est decrit en fonction 
des besoins du projet particulier. Le plan de management du projet doit etre suffisamment solide pour repondre a 
un environnement de projet en constante evolution. Cette flexibilite peut permettre de generer des informations plus 
precises a mesure que le projet avance. 

Le plan de management du projet doit reposer sur des references de base. En d’autres termes, il est necessaire 
de definir au moins les references du projet concernant le perimetre, la duree et le cout, afin de pouvoir mesurer et 
comparer I’execution du projet a ces references mais aussi en gerer les performances. Avant de definir les references 
de base, le plan de management du projet peut etre mis a jour autant de fois que necessaire. Aucun processus formel 
n’est requis a ce stade. Cependant, une fois fonde sur les references de base, il ne peut etre modifie que via le processus 
MaTtriser les changements. Des demandes de changement sont alors creees et traitees des qu’un changement est 
demande. Le plan de management du projet est done elabore progressivement grace a des mises a jour maitrisees et 
approuvees jusqu’a la cloture du projet. 

Pour les projets qui evoluent dans le contexte d’un programme ou d’un portefeuille, il y a lieu d’elaborer un plan de 
management du projet qui soit coherent avec le plan de management de programme ou de portefeuille. Par exemple, 
si le plan de management de programme indique que tous les changements depassant un cout specifie doivent etre 
passes en revue par le comite de maTtrise des changements, alors ce processus et le seuil de cout doivent etre definis 
dans le plan de management du projet. 


4.2.1 ELABORER LE PLAN DE MANAGEMENT DU PROJET : DONNEES D’ENTREE 

4.2.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. L’equipe projet se sert de la charte du projet comme point de depart pour la 
planification initiale. Le type et la quantite d’informations contenues dans la charte du projet dependent de la complexite 
du projet et de I’information connue au moment de sa creation. La charte du projet doit au moins definir les informations 
de haut niveau concernant le projet qui seront developpees dans les differents elements du plan de management du projet. 

4.2.1.2 DONNEES DE SORTIE D’AUTRES PROCESSUS 

Les donnees de sortie d’une grande partie des autres processus decrits dans les sections 5 a 13 sont integrees pour 
creer le plan de management du projet. Les references de base et les plans subsidiaires, qui sont des donnees de sortie 
d’autres processus de planification, sont des donnees d’entree de ce processus. De plus, les changements apportes a 
ces documents peuvent necessiter de reviser le plan de management du projet. 
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4.2.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Elaborer le 
plan de management du projet, on peut citer: 

♦ les standards gouvernementaux ou industriels (standards de produits, standards de qualite, standards de securite 
et standards de fabrication); 

♦ les exigences et/ou contraintes reglementaires et juridiques ; 

♦ le corpus des connaissances en management de projet (Guide PMBOK®) pour un marche vertical (par exemple, 
la construction) et/ou pour un domaine d’interet specifique (par exemple, I'environnement, la securite, le risque, 
ou le developpement agile de logiciels); 

♦ la structure organisationnelle et sa culture, les pratiques manageriales et leur perennite; 

♦ le cadre de gouvernance organisationnelle (un moyen structure d’apporter martrise, orientation et coordination 
grace a des personnes, des politiques et des processus, en vue d’atteindre des objectifs organisationnels 
strategies et operationnels); 

♦ I’infrastructure (par exemple, les installations et les biens d’equipement). 

4.2.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Elaborer le plan de management 
du projet, on peut citer: 

♦ les politiques, processus et procedures standardises de I'organisation ; 

♦ un modele du plan de management du projet, comprenant: 

■ des directives et des criteres d’adaptation de I'ensemble des processus standards de I’organisation, dans le 
but de satisfaire aux besoins specifies du projet, 

■ des directives ou des exigences liees a la cloture du projet, telles que la validation du produit et les criteres 
d’acceptation de celui-ci; 

♦ les procedures de maitrise des changements, comprenant les regies de changement des standards, des 
politiques, des plans et des procedures officiels ou de tout autre document de projet, ainsi que les modalites 
d’approbation et de validation de ces changements; 

♦ les methodes de martrise et de communication, les procedures de maitrise des risques et les exigences en 
matiere de communication; 

♦ les informations de projets anterieurs similaires (par exemple, les references de base de la performance, du 
perimetre, des couts et de I'echeancier, les calendriers du projet, les diagrammes de reseau du projet, les 
registres des risques); 

♦ le contexte historique et I’archive des retours d’experience. 
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4.2.2 ELABORER LE PLAN DE MANAGEMENT DU PROJET : OUTILS ET TECHNIQUES 


4.2.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant 
une connaissance specialist ou une formation dans les domaines suivants : 

♦ adaptation du processus de management de projet aux besoins du projet, y compris les dependances et les 
interactions entre les processus et les donnees d’entree et de sortie essentielles ; 

♦ ajout d’elements au plan de management du projet, si necessaire; 

♦ choix des outils et des techniques a utiliser pour executer ces processus; 

♦ developpement des details techniques et des informations de management a inclure dans le plan de management 
du projet; 

♦ definition des ressources et des niveaux de competence necessaires aux travaux du projet; 

♦ definition du niveau de gestion de la configuration a appliquer au projet; 

♦ choix des documents du projet qui seront soumis au processus formel de maTtrise des changements ; 

♦ etablissement des priorites de travail du projet afin de s'assurer que les ressources du projet sont allouees aux 
travaux appropries au moment opportun. 

4.2.2.2 COLLECTE DE DONNEES 

Parmi les techniques de collecte de donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Brainstorming. II est decrit a la section 4.1.2.2. Le brainstorming est frequemment utilise lors de I’elaboration du 
plan de management du projet pour reunir les idees et les solutions d’approche du projet. Les membres de I’equipe 
projet y participent. Toutefois, d’autres specialistes ou parties prenantes peuvent egalement y prendre part. 

♦ Listes de controle. Elies sont decrites a la section 11.2.2.2. De nombreuses organisations ont etabli des listes 
de controle standardises sur la base de leur propre experience ou utilisent des listes de controle specifiques a 
leur secteur d’activite. Une liste de controle peut aider le chef de projet a elaborer le plan ou verifier que toutes 
les informations requises figurent dans le plan de management du projet. 

♦ Groupes de discussion. Ms sont decrits a la section 5.2.2.2. Les groupes de discussion reunissent les parties 
prenantes pour discuter de la methode de management du projet et de I'integration des differents elements du 
plan de management du projet. 

♦ Entretiens. Ils sont decrits a la section 5.2.2.2. Les entretiens sont utilises pour obtenir des informations 
specifiques aupres des parties prenantes afin d’elaborer le plan de management du projet, le plan d’un element 
ou un document du projet. 
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4.2.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe utilisees dans le cadre de I'elaboration du plan de management 
du projet figurent notamment les elements suivants: 

♦ Gestion des conflits. Elle est decrite a la section 9.5.2.1. La gestion des conflits peut etre necessaire pour que 
les differentes parties prenantes s'alignent sur tous les aspects du plan de management du projet. 

♦ Facilitation. Elle est decrite a la section 4.1.2.3. La facilitation permet de veiller a la bonne participation, a ce 
que les participants se comprennent mutuellement, a ce que toutes les contributions soient prises en compte et 
a ce que les conclusions ou les resultats emportent une adhesion totale, conformement au processus decisionnel 
etabli pour le projet. 

♦ Gestion des reunions. Elle est decrite a la section 10.2.2.6. La gestion des reunions est necessaire pour garantir 
que les nombreuses reunions necessaires a I'elaboration, I’unification et I’adoption du plan de management du 
projet se deroulent correctement. 

4.2.2.4 REUNIONS 

Pour ce processus, les reunions sont utilisees pour examiner I’approche du projet, determiner la fagon d’accomplir 
les taches pour atteindre les objectifs du projet et etablir le processus de maTtrise du projet. 

La reunion de lancement du projet est generalement associee a la fin de la phase de planification et au debut de la 
phase d’execution. Elle a pour but de communiquer les objectifs du projet, d’obtenir I’engagement de I’equipe en faveur 
du projet et d’expliquer les roles et les responsabilites de chaque partie prenante. En fonction des caracteristiques du 
projet, le lancement peut avoir lieu a differents moments : 

♦ Pour les petits projets, une equipe s’occupe generalement de la planification et de I’execution. Dans ce cas, le 
lancement a lieu peu de temps apres le demarrage au sein du groupe de processus de planification, car I’equipe 
participe a la planification. 

♦ Pour les grands projets, une equipe de management de projet s’occupe de la majeure partie de la planification 
et les autres equipes projet interviennent a la fin de la planification initiate, au debut du developpement/de la 
mise en oeuvre. Dans ce cas, la reunion de lancement a lieu avec les processus au sein du groupe de processus 
d’execution. 

Les projets multiphases incluent generalement une reunion de lancement au debut de chaque phase. 

4.2.3 ELABORER LE PLAN DE MANAGEMENT DU PROJET : DONNEES DE SORTIE 

4.2.3.1 PLAN DE MANAGEMENT DU PROJET 

Le plan de management du projet est le document qui decrit comment le projet sera execute, maTtrise et clos. 
II integre et regroupe I’ensemble des references de base et des plans de management subsidiaires, ainsi que les autres 
informations necessaires pour manager le projet. Les besoins du projet determined les composants necessaires au 
plan de management du projet. 
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Les composants communs au plan de management du projet sont notamment les suivants : 

♦ Plans de management subsidiaires : 

■ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. II etablit la fagon dont le perimetre sera defini, 
elabore, maTtrise et valide. 

■ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. II etablit la maniere dont les exigences seront 
analysees, documentees et gerees. 

■ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. II etablit les criteres et les activites d’elaboration 
et de maTtrise de I'echeancier. 

■ Plan de gestion des couts. II est decrit a la section 7.1.3.1. II etablit la maniere dont les couts seront planifies, 
structures et martrises. 

■ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. II etablit la fagon dont les politiques, les 
methodologies et les standards de qualite d’une organisation seront appliques dans le cadre du projet. 

■ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. II donne des conseils sur la fagon dont les 
ressources du projet devraient etre classees, allouees, gerees et liberees. 

■ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. II etablit comment, quand et par qui 
les informations concernant le projet seront administrees et diffusees. 

■ Plan de gestion des risques. II est decrit a la section 11.1.3.1. II etablit comment les activites de gestion des 
risques seront structures et executees. 

■ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. II etablit comment Pequipe projet 
acquiert des biens et des services en dehors de I’organisation realisatrice. 

■ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. II etablit comment les parties 
prenantes seront impliquees dans les decisions et I’execution du projet, en fonction de leurs besoins, leurs 
interets et leur influence. 

♦ References de base: 

■ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. II s'agit de la version approuvee d’un 
enonce du perimetre, de I’organigramme des travaux du projet (work breakdown structure, WBS) et de son 
dictionnaire du WBS associe. Elle est utilisee comme base de comparaison. 

■ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. II s'agit de la version approuvee du 
modele d’echeancier, qui est utilisee comme base de comparaison avec les resultats reels. 

■ Reference de base des couts. Elle est decrite a la section 7.3.3.1. II s'agit de la version approuvee du budget 
echelonne du projet, qui est utilisee comme base de comparaison avec les resultats reels. 
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♦ Composants supplementaires. La majorite des composants du plan de management du projet sont produits 
comme des donnees de sortie d’autres processus, meme si certains sont produits au cours de ce processus. Les 
composants developpes dans le cadre de ce processus dependront du projet. Toutefois, ils incluent generalement 
les elements suivants: 

■ Plan de gestion des changements. II decrit comment les demandes de changement seront formellement 
autorisees et integrees tout au long du projet. 

■ Plan de gestion de la configuration. II decrit quels elements seront enregistres et mis a jour et comment les 
informations concernant ces elements seront enregistrees et mises a jour pour que le produit, le service ou 
le resultat du projet demeure coherent et/ou operationnel. 

■ Referentiel devaluation de la performance. Ce plan integre a la fois le perimetre, I’echeancier et les couts du 
projet, auxquels I’execution du projet est comparee pour mesurer et gerer les performances. 

■ Cycle de vie du projet. II decrit la serie de phases du projet, depuis son demarrage jusqu’a sa cloture. 

■ Approche de developpement. Elle decrit I'approche de developpement du produit, du service ou du resultat. 
II peut s’agir d’un modele predictif, iteratif, agile ou hybride. 

■ Revues de performance. Elies permettent d’identifier les moments du projet ou le chef de projet et les parties 
prenantes concernees en examinent I'avancement afin de determiner si la performance est conforme aux 
attentes ou si des actions preventives ou correctives sont necessaires. 

Bien que le plan de management du projet soit I’un des principaux documents utilises pour manager le projet, 
d’autres documents de projet sont egalement utilises. Ils ne font pas partie du plan de management du projet, mais 
sont necessaires pour mener a bien le projet. Le tableau 4-1 donne une liste representative des composants du plan de 
management du projet et des documents du projet. 
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Tableau 4-1. Plan de management du projet et documents du projet 


Plan de management du projet 

Documents du projet 

1. Plan de gestion du perimetre 

1. Attributs des activites 

19. Mesures de controie de la qualite 

2. Plan de gestion des exigences 

2. Liste d ’activites 

20. Metriques qualite 

3. Plan de gestion de I’echeancier 

3. Journal des hypotheses 

21. Rapport de qualite 

4. Plan de gestion des couts 

4. Base des estimations 

22. Documentation des exigences 

5. Plan de gestion de la qualite 

5. Journal des changements 

23. Matrice de tragabilite des exigences 

6. Plan de gestion des ressources 

6. Estimations de couts 

24. Organigramme des ressources 

7. Plan de gestion de la communication 

7. Previsions de couts 

25. Calendriers des ressources 

8. Plan de gestion des risques 

8. Estimations de durees 

26. Besoins en ressources 

9. Plan de gestion des approvisionnements 

9. Journal des points a traiter 

27. Registre des risques 

10. Plan d’engagement des parties prenantes 

10. Registre des retours d'experience 

28. Rapport sur les risques 

11. Plan de gestion des changements 

11. Liste des jalons 

29. Donnees de I’echeancier 

12. Plan de gestion de la configuration 

12. Affectations des ressources materielles 

30. Previsions de I’echeancier 

13. Reference de base du perimetre 

13. Calendriers du projet 

31. Registre des parties prenantes 

14. Reference de base de I’echeancier 

14. Communications du projet 

32. Charte d’equipe 

15. Reference de base des couts 

15. Echeancier du projet 

33. Documents devaluation et de test 

16. Reference de base de la performance 

16. Diagramme de reseau du projet 

17. Description du cycle de vie du projet 

17. Enonce du perimetre du projet 

18. Approche de developpement 

18. Affectations des membres de I’equipe projet 
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4.3 DIRIGER ET GERER LE TRAVAIL DU PROJET 


Diriger et gerer le travail du projet est le processus qui consiste a guider et a executer le travail defini dans le plan 
de management du projet et a appliquer les changements approuves pour atteindre les objectifs du projet. L’interet 
principal de ce processus est qu’il garantit une gestion globale du travail et des livrables du projet, ameliorant ainsi ses 
chances de reussite. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques 
et les donnees de sortie de ce processus sont represents sur la figure 4-6. La figure 4-7 represente le diagramme de 
flux de donnees du processus. 
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Figure 4-6. Diriger et gerer le travail du projet: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 4-7. Diriger et gerer le travail du projet: diagramme de flux de donnees 
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Le processus Diriger et gerer le travail du projet implique I’execution des activites du projet qui ont ete planifiees 
afin de realiser les livrables du projet et d’atteindre les objectifs fixes. Les ressources disponibles sont allouees, leur 
bonne utilisation est geree et, apres analyse des informations et donnees de performance d’execution, les plans du 
projet sont modifies en consequence. Le processus Diriger et gerer le travail du projet est directement affecte par le 
champ d’application du projet. Les livrables sont produits comme donnees de sortie des processus mis en oeuvre pour 
accomplir le travail du projet tel que cela a ete planifie et prevu dans le plan de management du projet. 

Le chef de projet et I'equipe de management de projet pilotent I’execution des activites du projet qui ont ete planifiees 
et gerent les diverses interfaces techniques et organisationnelles qui existent au sein du projet. Le processus Diriger et 
gerer le travail du projet exige egalement la revue de I'impact de tous les changements apportes au projet et I’application 
des changements approuves (action corrective, action preventive et/ou correction des defauts). 

Au cours de I'execution du projet, les donnees de performance d’execution sont collectees et communiquees aux 
processus de maTtrise applicables a des fins d’analyse. L'analyse des donnees de performance d’execution fournit des 
informations sur I'etat d'avancement des livrables et d’autres details pertinents concernant la performance du projet. 
Les donnees de performance d’execution seront egalement utilisees en tant que donnee d’entree pour le groupe de 
processus de maTtrise, et peuvent etre utilisees comme retour d’information dans le cadre des retours d’experience pour 
ameliorer I’execution des futurs lots de travaux. 


4.3.1 DIRIGER ET GERER LE TRAVAIL DU PROJET : DONNEES D’ENTREE 

4.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Tous les composants du plan de management du projet peuvent constituer des 
donnees d’entree pour ce processus. 

4.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Le journal des changements comprend I'etat de 
toutes les demandes de changement. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience sont utilises 
pour ameliorer I’execution du projet et eviter de refaire des erreurs. Le registre permet d’identifier la necessity 
d’etablir des regies ou des directives en vue d’aligner les actions de I’equipe. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons indique les dates prevues de 
jalons specifiques. 

♦ Communications du projet. Elies sont decrites a la section 10.2.3.1. Les communications du projet incluent les 
rapports sur la performance, I'etat des livrables et les autres informations generees par le projet. 
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♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier inclut au moins la liste d’activites de travail, 
leur duree, les ressources ainsi que les dates de debut et de fin prevues. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des 
exigences fait le lien entre les exigences du produit et les livrables qui y repondent. Elle permet egalement de se 
concentrer sur les resultats finaux. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques donne des informations sur les 
menaces et les opportunity qui peuvent avoir un impact sur I'execution du projet. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques donne des informations sur 
les sources du risque global du projet et recapitule les risques individuels identifies. 

4.3.1.3 DEMANDES DE CHANGEMENT APPROUVEES 

Elies sont decrites a la section 4.6.3.1. Les demandes de changement approuvees sont une donnee de sortie du 
processus MaTtriser les changements. Elies comprennent les demandes passees en revue et approuvees par le chef de 
projet ou le comite de maTtrise des changements a des fins d'application. La demande de changement approuvee peut 
etre une action corrective, une action preventive ou une correction de defaut. Les demandes de changement approuvees 
sont planifiees et appliquees par I'equipe projet et sont susceptibles d’avoir un impact sur n'importe quel domaine du 
projet ou du plan de management du projet. Les demandes de changement approuvees peuvent egalement modifier les 
composants du plan de management du projet formellement martrises ou les documents du projet. 

4.3.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Diriger et 
gerer le travail du projet, on peut citer: 

♦ la structure organisationnelle et sa culture, les pratiques manageriales et leur perennite; 

♦ I’infrastructure (par exemple, les installations et biens d’equipement existants); 

♦ les seuils de risque des parties prenantes (par exemple, le pourcentage autorise de depassement des couts). 
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4.3.1.5 ACTIFS ORGANISATION ELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Diriger et gerer le travail du projet, 
on peut citer: 

♦ les politiques, processus et procedures standardises de I'organisation ; 

♦ les procedures de gestion des points a traiter et des defauts definissant lafagon de les maTtriser, de les identifier 
et de les resoudre mais aussi le suivi de chaque action ; 

♦ les bases de donnees de gestion des points a traiter et des defauts, contenant un historique de leur etat, leur 
resolution et les resultats de chaque action ; 

♦ la base de donnees des mesures de performance utilisee pour collecter et mettre a disposition les donnees de 
mesures sur les processus et les produits ; 

♦ les procedures de martrise des risques et des changements ; 

♦ des informations de projets anterieurs (par exemple, les references de base de la performance, du perimetre, de 
I’echeancier et des couts, les calendriers du projet, les diagrammes de reseau du projet, les registres des risques, 
les rapports sur les risques et I'archive des retours d’experience). 

4.3.2 DIRIGER ET GERER LE TRAVAIL DU PROJET : OUTILS ET TECHNIQUES 
4.3.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1 . II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ connaissances techniques du secteur d’activite et du domaine d’interet specifique du projet; 

♦ gestion des couts et du budget; 

♦ affaires juridiques et approvisionnement; 

♦ legislation et regimentations ; 

♦ gouvernance organisationnelle. 
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4.3.2.2 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

Le systeme d'information de management du projet donne acces a des outils logiciels de technologie de I'information, 
comme les outils logiciels de planification, les systemes d’autorisation de travail, les systemes de gestion de la configuration 
et les systemes de collecte et de distribution des informations, ainsi qu'a des interfaces vers d’autres systemes automatises 
en ligne, notamment les registres de la base de connaissances de I’organisation. La collecte et I’etablissement des rapports 
automatises sur les indicateurs cles de la performance (KPI) peuvent faire partie de ce systeme. 

4.3.2.3 REUNIONS 

Les reunions sont un moyen de debattre et d’aborder des questions pertinentes concernant le projet lors de la 
direction et de la gestion du travail du projet. Parmi les participants, on peut compter le chef de projet, les membres de 
I’equipe projet et certaines autres parties prenantes impliquees ou affectees par les sujets qui sont discutes. Chacun des 
participants doit avoir un role bien defini pour assurer sa participation constructive. Parmi les types de reunion, on peut 
notamment citer les reunions de lancement, les reunions techniques, la planification d’iteration, les Scrums (melees 
quotidiennes), les comites de pilotage, les reunions de resolution des problemes, les reunions sur I’etat d’avancement 
et les reunions retrospectives. 


4.3.3 DIRIGER ET GERER LE TRAVAIL DU PROJET : DONNEES DE SORTIE 

4.3.3.1 LIVRABLES 

Un livrable est un produit, un resultat ou une capacite a realiser un service, au caractere unique et verifiable, qui doit 
etre produit pour achever un processus, une phase ou un projet. Les livrables sont generalement les resultats du projet. 
Ms peuvent egalement comprendre des elements du plan de management du projet. 

II convient de proceder a la maTtrise des changements des que la premiere version d’un livrable est achevee. La 
maTtrise des differentes versions ou editions d’un livrable (documents, logiciels et elements de base) est soutenue par 
des procedures et des outils de gestion de la configuration. 

4.3.3.2 DONNEES DE PERFORMANCE D’EXECUTION 

Les donnees de performance d’execution sont les observations brutes et les mesures relevees au cours de I'execution 
des activites pour accomplir le travail du projet. Les donnees sont souvent considerees comme le niveau de detail le plus 
bas a partir duquel les autres processus tirent I’information. Elies sont recueillies pendant I’execution du travail, puis 
transmises aux processus de martrise pour un complement d’analyse. 

Parmi les donnees de performance d’execution, on peut citer, par exemple, les travaux executes, les indicateurs cle 
de la performance du travail (KPI), les mesures de performance technique, les dates de debut et de fin des activites 
de I’echeancier, les story points acheves, I’etat des livrables, le nombre de demandes de changement concernant 
I’avancement par rapport a I’echeancier, le nombre de defauts ainsi que les durees, les couts reels, etc. 
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4.3.3.3 JOURNAL DES POINTS A TRAITER 


Tout au long du cycle de vie d’un projet, le chef de projet fera generalement face a des problemes, des ecarts, des 
incoherences ou des conflits qui surviennent brusquement et qui necessitent d’agir pour eviter tout impact sur la 
performance du projet. Le registre des points a traiter est un document de projet qui repertorie et permet de suivre tous 
les evenements. Les donnees concernant les points a traiter sont par exemple : 

♦ le type de point a traiter; 

♦ la personne qui I’a signale et le moment du signalement; 

♦ la description; 

♦ la priorite; 

♦ la personne en charge du point a traiter; 

♦ la date de resolution cible; 

♦ I’etat; 

♦ la solution finale. 

Le journal des points a traiter aidera le chef de projet a bien suivre et gerer les evenements, tout en garantissant leur 
analyse et leur resolution. II est cree pour la premiere fois en tant que donnee de sortie de ce processus, bien que des 
points a traiter puissent survenir a tout moment au cours du projet. Le journal des points a traiter est mis a jour a la suite 
des activites de martrise tout au long du cycle de vie du projet. 

4.3.3.4 DEMANDES DE CHANGEMENT 

Une demande de changement est une proposition formelle de modifier un document donne, un livrable ou une 
reference de base. Lorsque des problemes sont rencontres au cours de I’execution du travail du projet, des demandes 
de changement sont soumises, pouvant modifier les politiques ou les procedures du projet, le perimetre du projet ou 
le contenu du produit, le cout ou le budget, I'echeancier et la qualite du projet ou encore les resultats du projet ou 
du produit. D’autres demandes de changement portent sur les actions preventives ou correctives necessaires pour 
prevenir un impact negatif ulterieur dans le projet. Toute partie prenante peut deposer une demande de changement. 
Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements (voir la 
section 4.6). Les demandes de changement peuvent etre presentees de I’interieur ou de I’exterieur du projet. Elies 
peuvent etre facultatives ou constituer une obligation legale/contractuelle. Parmi les demandes de changement, on peut 
citer les elements suivants : 

♦ Action corrective. II s’agit d’une activite realisee dans I’intention de realigner la performance d’execution du 
projet avec le plan de management du projet. 

♦ Action preventive. II s’agit d’une activite realisee dans I’intention de s'assurer que la performance future du 
travail du projet est alignee sur le plan de management du projet. 

♦ Correction des detauts. II s’agit d’une activite realisee dans I'intention de modifier un produit ou un composant 
d’un produit non conforme. 

♦ Mises a jour. II s’agit des changements apportes a des plans ou des documents du projet formellement 
maitrises, de fagon a refleter les modifications ou les ajouts d’idees ou de contenu. 
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4.3.3.5 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I’organisation par Tintermediaire d’une demande de changement. Tous les composants du plan de management du 
projet peuvent necessiter une demande de changement a la suite de ce processus. 

4.3.3.6 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de Texecution de ce processus, figurent 
notamment les elements suivants : 

♦ Liste d’activites. Elle est decrite a la section 6.2.3.1. La liste d’activites peut etre mise a jour avec les activites 
supplementaires ou celles qui ont ete modifiees. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. De nouvelles hypotheses et contraintes peuvent etre 
ajoutees. En outre, I’etat des hypotheses et contraintes existantes peut etre mis a jour ou cloture. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1 .Tous les retours d’experience qui amelioreront 
la performance des projets actuels ou futurs sont enregistres au fur et a mesure. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. De nouvelles exigences peuvent etre 
identifies au cours de ce processus. Les progres accomplis pour satisfaire aux exigences peuvent egalement 
etre mis a jour. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. De nouveaux risques peuvent etre identifies. En outre, les 
risques existants peuvent etre mis a jour au cours de ce processus. Les risques sont enregistres dans le registre 
des risques via les processus de gestion des risques. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Lorsque d’autres informations sur les parties 
prenantes existantes ou nouvelles sont reunies a Tissue de ce processus, elles sont consignees dans le registre 
des parties prenantes. 

4.3.3.7 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Les actifs organisationnels peuvent etre mis a jour a la suite de ce processus. 
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4.4 GERER LES CONNAISSANCES DU PROJET 


Gerer les connaissances du projet est le processus qui consiste a utiliser les connaissances existantes et a acquerir 
de nouvelles connaissances pour atteindre les objectifs du projet et contribuer a I’apprentissage organisationnel. 
L'interet principal de ce processus tient a ce que les connaissances organisationnelles preambles sont exploitees pour 
produire ou ameliorer les resultats du projet et que les connaissances tirees du projet sont disponibles pour soutenir 
les operations organisationnelles et les futurs projets ou phases. Ce processus est execute tout au long du projet. Les 
donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la figure 4-8. 
La figure 4-9 represente le diagramme de flux de donnees du processus. 


Gerer les connaissances du projet 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 
•Tous les composants 
.2 Documents du projet 

• Registre des retours 
d'experience 

• Affectations des membres 
de I’equipe projet 

• Organigramme 
des ressources 

• Criteres de selection 
des sources 

• Registre des parties 
prenantes 

.3 Livrables 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v___y 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Gestion des connaissances 
.3 Gestion de I’information 
.4 Competences 

interpersonnelles et d'equipe 

• Ecoute active 

• Facilitation 

• Leadership 

• Networking 

• Conscience politique 

V___/ 


Donnees de sortie 


.1 Registre des retours 
d'experience 
.2 Mises a jour du plan 
de management du projet 
• Tout composant 
.3 Mises a jour des actifs 
organisationnels 

v_y 


Figure 4-8. Gerer les connaissances du projet: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 4-9. Gerer les connaissances du projet: diagramme de flux de donnees 
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Les connaissances sont generalement divisees en connaissances « explicites »(qui peuvent etre immediatement 
codifiees a I'aide de mots, d’images et de nombres) et en connaissances«tacites»(personnels et difficiles a exprimer, 
comme les croyances, les intuitions, I’experience et le«savoir-faire»). La gestion des connaissances concerne a la fois 
les connaissances tacites et explicites pour deux motifs : la reutilisation des connaissances existantes et la creation de 
nouvelles connaissances. Les principals activites qui appuient ces deux objectifs sont le partage et I’integration des 
connaissances (connaissances de differents domaines, contextuelles et en management de projet). 

On croit a tort que la gestion des connaissances suppose simplement de les documenter afin de pouvoir les partager. 
Une autre idee fausse tres repandue consiste a croire que la gestion des connaissances implique simplement d’acquerir 
des retours d’experience a la fin du projet, afin de les utiliser dans les projets futurs. Seules des connaissances explicites 
codifiees peuvent etre partagees de cette fagon. Cependant, les connaissances explicites codifiees manquent de 
contexte et sont susceptibles d’etre interpreters differemment. Ainsi, meme si elles peuvent etre facilement partagees, 
elles ne sont pas toujours comprises ou appliquees de la bonne maniere. Les connaissances tacites sont etablies 
dans un contexte, mais il est tres difficile de les codifier. Elles resident dans I'esprit d’experts individuels ou dans des 
situations et des groupes sociaux. En outre, elles sont habituellement partagees dans le cadre de conservations et 
d’echanges entre les personnes. 

D’un point de vue organisationnel, la gestion des connaissances consiste as’assurer que les competences, I’experience 
et I’expertise de I'equipe projet et des autres parties prenantes sont utilisees avant, pendant et apres le projet. Dans la 
mesure ou les connaissances resident dans I'esprit des gens et ou on ne peut forcer une personne a partager ce qu’elle 
sait (ou a faire attention aux connaissances des autres), la gestion des connaissances consiste essentiellement a creer 
une atmosphere de confiance afin de favoriser le partage des connaissances. Meme les meilleurs outils et techniques 
de gestion des connaissances ne fonctionneront pas si les gens ne sont pas encourages a partager ce qu’ils savent ou 
a faire attention a ce que les autres savent. Dans la pratique, elles sont partagees grace a une combinaison d’outils et 
de techniques de gestion des connaissances (echanges entre les personnes) et d’outils et de techniques de gestion de 
I’information (dans lesquels les personnes codifient une partie de leurs connaissances explicites en les documentant 
afin de pouvoir les partager). 


4.4.1 GERER LES CONNAISSANCES DU PROJET : DONNEES D’ENTREE 

4.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Tous les composants du plan de management du projet sont des donnees d’entree. 
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4.4.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience fournit 
des informations sur les pratiques efficaces en matiere de gestion des connaissances. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.1. Les affectations des 
membres de I’equipe projet donnent des informations sur le type de competences et d'experiences disponibles 
et sur les manquantes. 

♦ Organigramme des ressources. II est decrit a la section 9.2.3.3. L’organigramme des ressources inclut des 
informations sur la composition de I'equipe et peut aider a comprendre les connaissances disponibles au sein du 
groupe et les connaissances manquantes. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes contient des 
details sur les parties prenantes identifies qui aident a comprendre les connaissances qu’elles peuvent avoir. 

4.4.1.3 LIVRABLES 

Un livrable est un produit, un resultat ou une capacite a realiser un service, au caractere unique et verifiable, qui 
doit etre produit pour achever un processus, une phase ou un projet. Les livrables sont habituellement des composants 
tangibles realises pour atteindre les objectifs du projet. Ms peuvent egalement inclure des elements du plan de 
management du projet. 

4.4.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Gerer les 
connaissances du projet, on peut citer les elements suivants : 

♦ Culture de I’organisation, des parties prenantes et des clients. L'existence de relations professionnelles de 
confiance et une culture de tolerance sont particulierement importantes pour la gestion des connaissances. Les 
autres facteurs incluent notamment la valeur accordee a I’enseignement et aux standards de comportement social. 

♦ Repartition geographique des installations et des ressources. La localisation des membres de I’equipe 
permet de determiner les methodes d’acquisition et de partage des connaissances. 

♦ Experts des connaissances de I’organisation. Certaines organisations ont une equipe ou une personne 
specialist dans la gestion des connaissances. 

♦ Exigences et/ou contraintes reglementaires et juridiques. Elies incluent la confidentialite des informations 
du projet. 
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4.4.1.5 ACTIFS ORGANISATION ELS 


Les connaissances en management de projet sont souvent integrees aux processus et aux routines. Parmi les actifs 
organisationnels qui peuvent avoir une influence sur le processus Gerer les connaissances du projet, on peut citer les 
elements suivants: 

♦ Politiques, processus et procedures standardises de I’organisation. II s'agit notamment de la confidentiality, 
de I’acces a I’information, de la security et de la protection des donnees, des politiques de conservation des 
documents, de I’utilisation d'informations protegees par des droits d’auteur, de la destruction d’informations 
classees, du format et de la taille maximale des fichiers, des donnees et des metadonnees des registres, de la 
technologie autorisee et des medias sociaux. 

♦ Administration du personnel. Elle concerne, par exemple, les documents de formation et le developpement des 
salaries, ainsi que les environnements de competence lies aux comportements de partage des connaissances. 

♦ Exigences de I’organisation en matiere de communication. Des exigences de communication formelles et 
strictes sont utiles pour le partage d’informations. Une communication informelle est plus efficace pour creer de 
nouvelles connaissances et les integrer au sein des differents groupes de parties prenantes. 

♦ Procedures formelles de partage des connaissances et des informations. Elies comprennent la revision des 
retours d’experience avant, pendant et apres les projets et les phases du projet, par exemple, I’identification, la 
collecte et le partage des connaissances a partir du projet actuel et d’autres projets. 

4.4.2 GERER LES CONNAISSANCES DU PROJET : OUTILS ET TECHNIQUES 

4.4.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ gestion des connaissances; 

♦ gestion de I’information ; 

♦ apprentissage organisationnel; 

♦ outils de gestion des connaissances et de I’information ; 

♦ informations pertinentes des autres projets. 

4.4.2.2 GESTION DES CONNAISSANCES 

Les outils et techniques de gestion des connaissances connectent les gens afin qu’ils puissent travailler ensemble a 
la creation de nouvelles connaissances, au partage de connaissances tacites et a I’integration des connaissances des 
divers membres de I’equipe. Les outils et techniques appropries dans le cadre d'un projet dependent de sa nature, en 
particulier du degre d’innovation induit, de la complexity du projet et du niveau de diversity (y compris la diversity des 
disciplines) entre les membres de I’equipe. 
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Ces outils et techniques comprennent, entre autres: 

♦ le networking, notamment les echanges sociaux informels et le networking social en ligne ; les forums en ligne 
sur lesquels on peut poser des questions ouvertes (Que savez-vous a propos de... ?) et qui sont utiles pour lancer 
des conversations sur le partage des connaissances avec des specialistes ; 

♦ les communautes de pratique (parfois appelees communautes d’interet ou simplement communautes) et les 
groupes d’interet speciaux; 

♦ les reunions, y compris les reunions virtuelles ou les participants peuvent interagir grace aux technologies 
de communication; 

♦ I’apprentissage par I’observation ; 

♦ les forums de discussion comme les groupes de discussion ; 

♦ les evenements de partage des connaissances, comme les seminaires et les conferences; 

♦ les ateliers, y compris les seances de resolution de problemes et les revues visant a identifier les retours 
d’experience; 

♦ les recits; 

♦ les techniques de creativite et de gestion des idees; 

♦ les foires d’echange et les cafes ; 

♦ la formation qui implique une interaction entre les apprenants. 

L'ensemble de ces outils et techniques peut etre utilise en face a face ou virtuellement, ou les deux a la fois. Le 
face-a-face est generalement le moyen le plus efficace d’etablir les relations de confiance necessaires a la gestion des 
connaissances. Une fois etablies, ces relations peuvent etre entretenues grace a une interaction virtuelle. 

4.4.2.3 GESTION DE L’INFORMATION 

Les outils et techniques de gestion de I'information sont utilises pour connecter les individus a I’information. Ils sont 
efficaces pour partager des connaissances explicites simples, claires et codifiees. Ils comprennent, entre autres : 

♦ les methodes de codification des connaissances explicites, par exemple, pour produire des entrees destinees au 
registre des retours d’experience ; 

♦ le registre des retours d’experience; 

♦ les services de bibliotheque ; 

♦ la collecte d’informations, par exemple, les recherches sur le Web et la lecture d'articles publies ; 

♦ le systeme d’information de management du projet (PMIS). II est decrit a la section 4.3.2.2. Les systemes 
d’information de management du projet (PMIS) comprennent souvent des systemes de gestion des documents. 

Les outils et techniques qui connectent les individus a I’information peuvent etre renforces grace a I’ajout d’un 
element d'interaction, comme une fonction«Contact», qui permet aux utilisateurs d’entrer en contact avec les auteurs 
des retours d’experience pour leur demander des conseils specifiques a leur projet et leur contexte. 
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L’interaction et le soutien permettent egalement de trouver des informations pertinentes. II est generalement plus 
rapide et facile de demander de I'aide que d'essayer d'identifier les criteres de recherche. En effet, ces derniers sont 
souvent difficiles a selectionner, car les gens peuvent ne pas savoir quels mots cles ou phrases cles utiliser pour acceder 
aux informations dont ils ont besoin. 

Les outils et techniques de gestion des connaissances et des informations doivent etre connectes aux processus du 
projet et aux personnes chargees de ces processus. Les communautes de pratique et les specialistes, par exemple, 
peuvent generer des connaissances qui aboutissent a des processus de controle ameliores. Par ailleurs, la presence 
d’un sponsor interne peut garantir I’implementation des ameliorations. Les entrees du registre des retours d’experience 
peuvent etre analysees pour identifier les points a traiter communs pouvant etre resolus par des changements apportes 
aux procedures du projet. 

4.4.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees figurent notamment les elements suivants: 

♦ Ecoute active. Elle est decrite a la section 10.2.2.6. L'ecoute active permet de reduire les malentendus et 
d’ameliorer la communication et le partage des connaissances. 

♦ Facilitation. Elle est decrite a la section 4.1.2.3. La facilitation permet de guider le groupe vers une decision, une 
solution ou une conclusion efficace. 

♦ Leadership. II est decrit a la section 3.4.4. Le leadership est utilise pour communiquer la vision et motiver 
I’equipe projet a se concentrer sur les connaissances utiles et les objectifs en la matiere. 

♦ Networking. II est decrit a la section 10.2.2.6. Le networking permet d’etablir des relations et des connexions 
informelles entre les parties prenantes du projet. En outre, il cree les conditions propices au partage des 
connaissances tacites et explicites. 

♦ Conscience politique. Elle est decrite a la section 10.1.2.6. La conscience politique permet au chef de projet 
de planifier les communications en fonction de I’environnement du projet et de I’environnement politique de 
I’organisation. 

4.4.3 GERER LES CONNAISSANCES DU PROJET : DONNEES DE SORTIE 

4.4.3.1 REGISTRE DES RETOURS D’EXPERIENCE 

Le registre des retours d’experience peut inclure leur categorie et la description de la situation rencontree. II peut 
egalement comprendre I’impact, les recommandations et les actions proposees en rapport avec la situation. Le registre 
des retours d’experience peut presenter les difficulty, les points a traiter, les menaces et les opportunity realises ou 
d’autres contenus, selon le cas. 

Le registre des retours d’experiences est cree en tant que donnee de sortie de ce processus au debut du projet. II sera 
ensuite utilise comme une donnee d’entree, puis mis a jour en tant que donnee de sortie dans de nombreux processus 
tout au long du projet. Les personnes ou les equipes accomplissant le travail participent egalement a la collecte des 
retours d’experience. Les connaissances peuvent etre documentees a I’aide de videos, d’images, de supports audio ou 
de tout autre moyen approprie qui garantit la pertinence des retours d’experience recueillis. 

A la fin d’un projet ou d’une phase, les informations sont transferees vers un actif organisationnel appele archive des 
retours d’experience. 
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4.4.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I’organisation par I’intermediaire d’une demande de changement. Tous les composants du plan de management du 
projet peuvent etre mis a jour a la suite de ce processus. 

4.4.3.3 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Tous les projets creent de nouvelles connaissances. Certaines de ces connaissances sont codifiees ou bien integrees 
aux livrables ou aux ameliorations des processus et des procedures a la suite du processus Gerer les connaissances 
du projet. Les connaissances existantes peuvent aussi etre codifiees ou integrees pour la premiere fois a la suite de ce 
processus, par exemple si une idee existante concernant une nouvelle procedure est appliquee avec succes dans le 
contexte du projet. 

Les actifs organisationnels peuvent etre mis a jour a la suite de ce processus. 


4.5 MAITRISER LE TRAVAIL DU PROJET 

MaTtriser le travail du projet est le processus qui consiste a suivre, passer en revue et communiquer I’avancement 
global par rapport aux objectifs de performance definis au plan de management du projet. L’interet principal de ce 
processus est qu'il permet aux parties prenantes de comprendre I’etat actuel du projet, de reconnaftre les mesures prises 
pour traiter les ecarts de performance et d’avoir une visibility sur son etat futur avec des previsions sur I’echeancier 
et les couts. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques et les 
donnees de sortie de ce processus sont represents sur la figure 4-10. La figure 4-11 represente le diagramme de flux 
de donnees du processus. 


Maitriser le travail du projet 


Donnees d’entree V Outils et techniques V Donnees de sortie 


1 Elaborer le plan 
de management du projet 

• Tout composant 

.2 Documents du projet 

• Journal des hypotheses 

• Base des estimations 

• Previsions de couts 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Liste des jalons 

• Rapport de qualite 

• Registre des risques 

• Rapport sur les risques 

• Previsions de I'echeancier 
.3 Information sur 

la performance d'execution 
.4 Accords 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
V___ 


.1 Jugement a dire d'expert 
.2 Analyse des donnees 
•Analyse des alternatives 
•Analyse cout-benefice 
•Analyse de la valeur acquise 
•Analyse des causes 
fondamentales 
• Analyse de la tendance 
•Analyse des ecarts 
.3 Prise de decision 
.4 Reunions 

V_ 


A Rapports sur la performance 
d'execution 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 

• Tout composant 

.4 Mises a jour des documents 
du projet 

• Previsions de couts 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Registre des risques 

• Previsions de I'echeancier 

V_/ 


Figure 4-10. Maitriser le travail du projet: donnees d’entree, outils, techniques et donnees de sortie 
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de management 
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Plan de management du projet 
• Tout composant 


> Demandes de changement 
■ Rapports sur la performance d’execution 


> Rapports sur la performance d’execution 


4.6 

Effectuer 

la gestion integree 
des changements 


9.5 

Gerer I'equipe 


Documents 
du projet 


Documents du projet 

• Journal des hypotheses 

• Base des estimations 

• Previsions de couts 

• Journal des points a traiter 

• Registre des retours d’experience 

• Liste des jalons 

• Rapport de qualite 

• Registre des risques 

• Rapport sur les risques 

• Previsions de I’echeancier 


12.2 

Proceder aux 
approvisionnements 


> Rapports sur la performance d’execution 


> Rapports sur la performance d’execution 


10.2 
Gerer les 
communications 


11.7 
MaTtriser 
les risques 


4.5 

MaTtriser 
le travail 
du projet 


Mises a jour du plan 
de management du projet 
• Tout composant 


Plan 

de management 
du projet 


Mises a jour des documents 
du projet 

• Previsions de couts 

• Journal des points a traiter 

• Registre des retours d'experience 

• Registre des risques 

• Previsions de I’echeancier 


Documents 
du projet 


■ Facteurs environnementaux de I’organisation 

■ Actifs organisationnels 


Entreprise 

Organisation 


• Information sur la performance d'execution 


i. 



5.5 

Valider 
le perimetre 


: 


6.6 

MaTtriser 

I'echeancier 




10.3 

MaTtriser les 
communications 



: 



5.6 

MaTtriser 
le perimetre 
et le contenu 




7.4 

MaTtriser 
les couts 


J 


11.7 
MaTtriser 
les risques 



! 



8.3 

MaTtriser 
la qualite 




12.3 

MaTtriser les 
approvisionnements 




9.6 

MaTtriser 
les ressources 


• 


13.4 
MaTtriser 
I’engagement 
des parties 
prenantes 



Figure 4-11. MaTtriser le travail du projet: diagramme de flux de donnees 
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La maTtrise est une activite de management de projet qui est effectuee tout au long de I'execution du projet. Elle 
consiste a collecter, mesurer et evaluer les mesures et les tendances qui vont permettre d’apporter des ameliorations 
aux processus. Cette maTtrise continue donne a I’equipe de management de projet un apergu du statut du projet et 
identifie les domaines qui requierent une attention particuliere. La maTtrise consiste notamment a determiner les actions 
correctives ou preventives ou a replanifier et a suivre les plans d'action, afin de verifier si les actions entreprises ont 
permis de resoudre les ecarts de performance. Le processus MaTtriser le travail du projet consiste a: 

♦ comparer la performance reelle du projet avec le plan de management du projet; 

♦ evaluer periodiquement la performance de fagon a evaluer le besoin d’actions correctives ou preventives, puis 
recommander celles qui sont jugees necessaires ; 

♦ verifier I’etat des risques individuels du projet; 

♦ maintenir, toutau long de I’execution du projet, une base d'informations precises etopportunes sur le(s) produit(s) 
du projet et la documentation qui leur est associee; 

♦ fournir I’information necessaire aux rapports d’etat, a la mesure de I’avancement et aux previsions ; 

♦ fournir les previsions permettant la mise a jour des informations relatives aux couts et a I’echeancier actuels ; 

♦ maTtriser la mise en oeuvre des changements approuves au fur et a mesure ; 

♦ fournir au management de programme des rapports appropries sur I’avancement et I'etat du projet, lorsque le 
projet fait partie d’un programme global; 

♦ s'assurer que le projet reste conforme aux besoins de I’organisation. 

4.5.1 MAlTRISER LE TRAVAIL DU PROJET : DONNEES D’ENTREE 

4.5.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. La maTtrise du projet implique de considerer tous les aspects du projet. Tous les 
composants du plan de management du projet peuvent constituer des donnees d’entree pour ce processus. 
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4.5.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses contient des informations 
sur les hypotheses et les contraintes identifies comme affectant le projet. 

♦ Base des estimations. Elle est decrite dans les sections 6.4.3.2 et 7.2.3.2. La base des estimations indique 
comment les differentes estimations ont ete obtenues. Elle peut etre utilisee pour prendre une decision sur la 
fagon de repondre aux ecarts. 

♦ Previsions de couts. Elies sont decrites a la section 7.4.3.2. En fonction de la performance passee du projet, les 
previsions de couts sont utilisees pour determiner si le projet se situe dans les limites de tolerance budgetaire et 
identifier toutes demandes de changement necessaires. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter peut servir pour 
documenter et martriser la resolution d’evenements specifiques avant une date cible. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
contenir des informations sur des reponses efficaces aux ecarts mais aussi des actions correctives et preventives. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons indique les dates prevues pour des jalons 
specifiques. Elle est utilisee pour verifier si les jalons planifies ont ete respectes. 

♦ Rapports de qualite. Ils sont decrits a la section 8.2.3.1. Le rapport de qualite inclut les aspects de gestion de 
la qualite, des recommandations de processus, les ameliorations du projet et du produit, des recommandations 
d’actions correctives (reprise, correction de defaut/bug, inspection 100 %, etc.) et le recapitulate des conclusions 
du processus Martriser la qualite. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques donne des informations sur les 
menaces et les opportunity qui se sont presentees au cours de I’execution du projet. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques donne des informations sur 
les risques globaux du projet ainsi que des informations sur des risques individuels specifiques. 

♦ Previsions de I’echeancier. Elies sont decrites a la section 6.6.3.2. En fonction de la performance passee 
du projet, les previsions de I’echeancier sont utilisees pour determiner si le projet se situe dans les limites de 
tolerance temporelles definies et identifier toute demande de changement necessaire. 
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4.5.1.3 INFORMATIONS SUR LA PERFORMANCE D’EXECUTION 


Les donnees de performance d’execution sont recueillies pendant I'execution du travail avant d'etre transmises 
aux processus de maTtrise. Pour devenir des donnees de performance d’execution, ces informations sont comparees 
aux composants du plan de management du projet, aux documents du projet et aux autres variables du projet. Cette 
comparaison donne des indications sur la performance d’execution du projet. 

Des metriques specifiques a la performance d’execution sont definies en debut de projet dans le cadre du plan de 
management du projet pour le perimetre, I’echeancier, le budget et la qualite. Les donnees sur la performance sont 
recueillies au cours du projet par I'intermediaire des processus de controle, puis comparees avec le plan et les autres 
variables afin d’inscrire la performance d'execution dans un contexte. 

Par exemple, les donnees de performance d’execution liees aux couts peuvent inclure les fonds qui ont ete depenses. 
Neanmoins, pour etre utiles, ces donnees doivent etre comparees au budget, au travail qui a ete effectue, aux ressources 
utilisees pour accomplir le travail et au plan de financement. Ces informations supplementaires donnent le contexte pour 
determiner si le projet respecte le budget ou s’il y a un ecart. Elies indiquent egalement le degre d’ecart par rapport 
au plan. En les comparant aux seuils d’ecart dans le plan de management du projet, elles peuvent indiquer si une 
action preventive ou corrective est necessaire. L'interpretation globale des donnees de performance d'execution et des 
informations supplementaires offre un contexte qui constitue une base solide pour les decisions du projet. 

4.5.1.4 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Un accord d’approvisionnement comprend des conditions generates et peut 
comporter d’autres elements specifies par I’acheteur pour definir ce que le fournisseur sera appele a executer ou a 
fournir. Si le projet consiste a externaliser une partie du travail, le chef de projet doit superviser le travail du sous-traitant 
afin de s'assurer que tous les accords satisfont aux besoins specifiques du projet tout en respectant les politiques 
d’approvisionnement de I'organisation. 

4.5.1.5 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus MaTtriser le 
travail du projet, on peut citer: 

♦ les systemes d’information du management de projet (PMIS), comme les outils de planification, de couts et de 
ressources, les indicateurs de performance, les bases de donnees, les enregistrements du projet et les donnees 
financiers; 

♦ I’infrastructure (par exemple, les installations et les equipements existants ou les canaux de communication 
de I’organisation); 

♦ les attentes des parties prenantes et les seuils de risque ; 

♦ les standards gouvernementaux ou industriels (par exemple, les reglementations des organismes de normalisation, 
les standards de produits, les standards de qualite et les standards de fabrication). 
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4.5.1.6 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser le projet, on peut citer: 

♦ les politiques, processus et procedures standardises de I’organisation ; 

♦ les procedures de controle financier (par exemple, les audits de depenses et de debours, les codes d’imputation 
comptable et les provisions contractuelles standardises); 

♦ les methodes de maitrise et de communication ; 

♦ les procedures de gestion des points a traiter definissant la fagon de les maTtriser, leur identification et leur 
resolution, ainsi que le suivi de chaque action ; 

♦ les procedures de gestion des defauts definissant la fagon de les maTtriser, leur identification et leur resolution, 
ainsi que le suivi de chaque action ; 

♦ la base de connaissances de I'organisation, en particulier la mesure du processus et I’archive des retours 
d’experience. 

4.5.2 MAITRISER LE PROJET : OUTILS ET TECHNIQUES 
4.5.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ analyse de la valeur acquise (EVM); 

♦ interpretation et contextualisation des donnees ; 

♦ techniques d’estimation de la duree et des couts ; 

♦ analyse de la tendance; 

♦ connaissances techniques du secteur d’activite et du domaine d’interet specifique du projet; 

♦ gestion des risques ; 

♦ gestion des contrats. 
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4.5.2.2 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees figurent notamment les elements suivants: 

♦ Analyse des alternatives. L’analyse des alternatives est utilisee pour selectionner les actions correctives ou une 
combinaison d'actions correctives et preventives a appliquer en cas d’ecart. 

♦ Analyse cout-benefice. Elle est decrite a la section 8.1.2.3. L’analyse cout-benefice permet de determiner les 
meilleures actions correctives en termes de cout en cas d’ecarts avec les references de base du projet. 

♦ Analyse de la valeur acquise (EVM). Elle est decrite a la section 7.4.2.2. La valeur acquise offre une perspective 
integree quant au perimetre, a I’echeancier et a la performance des couts. 

♦ Analyse des causes originelles. Elle est decrite a la section 8.2.2.2. L’analyse des causes originelles vise a 
identifier les principales raisons d’un probleme. Elle peut etre utilisee pour identifier les raisons d’un ecart et les 
domaines sur lesquels le chef de projet devrait se concentrer afin d’atteindre les objectifs du projet. 

♦ Analyse de la tendance. L'analyse de la tendance est utilisee pour prevoir la performance future sur la base des 
resultats precedents. Elle envisage les derapages attendus dans le cadre du projet et previent le chef de projet 
que des problemes pourraient se poser ulterieurement dans I’echeancier si les tendances etablies perdurent. Ces 
informations sont presentees suffisamment tot afin de donner a I’equipe projet le temps d’analyser et de corriger 
les anomalies. Les resultats de l’analyse de la tendance peuvent etre utilises pour recommander des actions 
preventives, si necessaire. 

♦ Analyse des ecarts. L’analyse des ecarts passe en revue les differences (ou ecarts) entre la performance prevue 
et la performance reelle. Elies peuvent concerner les estimations de duree, les estimations de cout, I'utilisation 
des ressources, les tarifs des ressources, la performance technique et d’autres metriques. 

L’analyse des ecarts peut etre realisee dans chaque domaine de connaissances en fonction de ses variables 
specifiques. Dans le processus MaTtriser le projet, l’analyse des ecarts examine les ecarts dans une perspective 
integree et prend en consideration les ecarts de cout, de duree, techniques et de ressources les uns par 
rapport aux autres afin d’apprecier I'ecart global du projet. Cela permet de lancer les actions preventives ou 
correctives appropriees. 

4.5.2.3 PRISE DE DECISION 

Parmi les techniques de prise de decision pouvant etre utilisees figure notamment le vote. Decrit a la section 5.2.2.4, 
le vote peut inclure la prise de decisions a I’unanimite, a la majorite ou a la plurality. 

4.5.2.4 REUNIONS 

Les reunions peuvent etre en face a face, virtuelles, formelles ou informelles. Elies peuvent compter des membres de 
Pequipe projet et d’autres parties prenantes du projet, selon le cas. Parmi les types de reunions figurent les reunions de 
groupes d'utilisateurs et les reunions de revue. 
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4.5.3 MAITRISER LE PROJET : DONNEES DE SORTIE 


4.5.3.1 RAPPORTS SUR LA PERFORMANCE D’EXECUTION 

Les informations sur la performance d’execution sont regroupees, enregistrees et diffusees au format papier ou 
electronique afin de sensibiliser et de generer des decisions ou des actions. Les rapports sur la performance d’execution 
sont la representation papier ou electronique des informations sur la performance d’execution destinees a generer des 
decisions, des actions ou une sensibilisation. Ils sont transmis aux parties prenantes du projet via les processus de 
communication, comme definis dans le plan de gestion des communications du projet. 

Les rapports sur la performance d’execution incluent, par exemple, les rapports d’etat et les rapports d'avancement. 
Les rapports sur la performance d'execution peuvent contenir des graphiques et des informations sur la valeur acquise, 
les previsions et les lignes de tendance, des diagrammes de consommation des reserves («reserve burndown charts»), 
des histogrammes des defauts, des informations sur I’execution du contrat et des syntheses des risques. Ils peuvent etre 
presentes sous la forme de tableaux de bord, de diagrammes a code couleur ou d’autres representations utiles pour creer 
une sensibilisation et generer des decisions et des actions. 

4.5.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. La comparaison des resultats reels avec les resultats prevus peut conduire 
a I’etablissement de demandes de changement capables d’elargir, de rectifier ou de reduire le perimetre du projet ou 
le contenu du produit, les exigences de qualite ou les references de base de I’echeancier ou des couts. Les demandes 
de changement peuvent exiger de collecter et de documenter de nouvelles exigences. Les changements peuvent 
avoir un impact sur le plan de management du projet, sur les documents du projet ou sur les livrables de type produit. 
Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements (voir la 
section 4.6). Les changements comprennent notamment les elements suivants : 

♦ Action corrective. II s’agit d’une activite realisee dans I’intention de realigner la performance d’execution du 
projet avec le plan de management du projet. 

♦ Action preventive. II s'agit d’une activite realisee dans I’intention de s’assurer que la performance future du 
travail du projet est alignee sur le plan de management du projet. 

♦ Correction des defauts. II s'agit d’une activite executee dans I’intention de modifier un produit ou un composant 
de produit non conforme. 

4.5.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I'organisation par I’intermediaire d’une demande de changement. Les changements identifies au cours du processus 
MaTtriser le projet peuvent affecter le plan de management global du projet. 
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4.5.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Previsions de couts. Elies sont decrites a la section 7.4.3.2. Les changements lies aux previsions de couts 
resultant de ce processus sont enregistres a I'aide des processus de gestion des couts. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les nouveaux points a traiter souleves a la suite 
de ce processus sont enregistres dans le journal des points a traiter. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour afin d’inclure les reponses correctives et preventives appropriees aux ecarts. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies au cours de ce processus 
sont enregistres dans le registre des risques et geres a I'aide des processus de gestion des risques. 

♦ Previsions de I’echeancier. Elies sont decrites a la section 6.6.3.2. Les changements lies aux previsions de 
I'echeancier resultant de ce processus sont enregistres a I'aide des processus de gestion de I'echeancier. 


4.6 MAITRISER LES CHANGEMENTS 

MaTtriser les changements est le processus qui consiste a passer en revue toutes les demandes de changement, a 
approuver les changements, a gerer les changements apportes aux livrables, aux documents du projet et au plan de 
management du projet mais aussi a communiquer les decisions. Ce processus passe en revue toutes les demandes 
de changement concernant les documents du projet, les livrables ou le plan de management du projet et determine la 
reponse a donner a ces demandes. L'interet principal de ce processus est qu’il permet de considerer les changements 
documents au sein du projet de maniere integree, tout en gerant le risque global du projet, qui est souvent la resultante 
de changements ayant ete integres sans tenir compte des plans ou des objectifs globaux du projet. Ce processus est 
execute tout au long du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus 
sont represents sur la figure 4-12. La figure 4-13 represente le diagramme de flux de donnees du processus. 


Effectuer la gestion integree des changements 


Donnees d’entree 


.1 Elaborer le plan 
de management du projet 

• Plan de gestion 
des changements 

• Plan de gestion 

de la configuration 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

.2 Documents du projet 

• Base des estimations 

• Matrice de tragabilite 
des exigences 

• Rapport sur les risques 

.3 Rapports sur la performance 
d'execution 

.4 Demandes de changement 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
v___/ 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Outils de maftrise 
des changements 
.3 Analyse des donnees 

• Analyse des alternatives 

• Analyse cout-benefice 
.4 Prise de decision 

• Vote 

• Prise de decision 
autocratique 

• Analyse decisionnelle 
multicritere 

.5 Reunions 

V_/ 


Donnees de sortie 


.1 Demandes de changement 
approuvees 
.2 Mises a jour du plan 
de management du projet 

• Tout composant 

.3 Mises a jour des documents 
du projet 

• Journal des changements 

V___ J 


Figure 4-12. Maitriser les changements: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 4-13. Maitriser les changements : diagramme de flux de donnees 
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Le processus MaTtriser les changements est conduit du debut a la fin du projet, sous la responsabilite ultime du 
chef de projet. Les demandes de changement peuvent influersur le perimetre du projet, sur le contenu du produit et 
sur les composants du plan de management du projet ou tout document du projet. Toute partie prenante participant 
au projet peut demander un changement, qui peut etre applique a tout moment pendant le cycle de vie du projet. La 
rigueur de la maTtrise des changements est fonction du champ d’application, de la complexity du projet en cause, des 
exigences du contrat, ainsi que du contexte et de I'environnement dans lequel le projet est execute. 

Avant d’etablir les references de base, il n’est pas necessaire de maitriser formellement les changements via le 
processus Maitriser les changements. Une fois que le projet repose sur des references de base, les demandes de 
changement passent par ce processus. En regie generate, chaque plan de gestion de la configuration du projet doit 
definir les elements du projet qui necessitent de controler la configuration. Tout changement d’un element de la 
configuration doit etre formellement maTtrise et necessitera une demande de changement. 

Bien que les demandes puissent etre initiees verbalement, elles doivent etre enregistrees par ecrit et saisies dans le 
systeme de gestion de la configuration et/ou des changements. Avant I’approbation d’une demande de changement, 
il peut etre necessaire de fournir des informations concernant les impacts estimes sur I'echeancier et sur le cout. 
Des lors qu’une demande de changement est susceptible d’influer sur les references de base du projet, un processus 
de maTtrise des changements formel est toujours requis. Chaque demande de changement documentee doit etre 
soit approuvee, soit rejetee par une personne responsable, generalement le sponsor du projet ou le chef de projet. 
Le responsable sera identifie dans le plan de management du projet ou par les procedures organisationnelles. Le 
processus MaTtriser les changements inclut, le cas echeant, un comite de gestion des changements (Change Control 
Board, CBB). C’est un groupe officiellement charge de passer en revue les demandes de changement du projet, de les 
evaluer, de les approuver, de les differer ou de les refuser, ainsi que d’enregistrer et de communiquer ces decisions. 

Les demandes de changement approuvees peuvent necessiter une revision, voire la refonte complete, des 
estimations de couts, des sequences d’activites, des dates de I’echeancier, des besoins en ressources et/ou 
de I'analyse des differentes reponses aux risques. Ces changements peuvent necessiter de rectifier le plan de 
management du projet et d’autres documents du projet. L'approbation du client ou du sponsor peut etre requise pour 
certaines demandes de changement, apres l’approbation du comite de maTtrise des changements, a moins qu’ils ne 
fassent eux-memes partie de ce comite. 
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4.6.1 MAITRISER LES CHANGEMENTS : DONNEES D’ENTREE 


4.6.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment les suivants: 

♦ Plan de gestion des changements. II est decrit a la section 4.2.3.1. Le plan de gestion des changements fournit 
les directives pour gerer le processus de maitrise des changements et definit les roles et les responsabilites du 
comite de maitrise des changements. 

♦ Plan de gestion de la configuration. II est decrit a la section 4.2.3.1. Le plan de gestion de la configuration 
decrit les elements du projet qui peuvent etre configures et recense les elements qui seront enregistres et mis 
a jour afin que le produit du projet demeure coherent et exploitable. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre donne 
la definition du projet et du produit. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. La reference de base de I'echeancier 
est utilisee pour evaluer I’impact des changements sur I'echeancier du projet. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts est utilisee 
pour evaluer I’impact des changements sur le cout du projet. 

4.6.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Base des estimations. Elle est decrite a la section 6.4.3.2. La base des estimations indique comment les 
estimations de duree, de cout et de ressources ont ete deduites et peuvent etre utilisees pour calculer I’impact 
du changement sur la duree, le budget et les ressources. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
permet d’evaluer I'impact du changement sur le perimetre du projet. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques presente des informations 
sur les sources de risques individuels et globaux du projet, induits par le changement demande. 

4.6.1.3 RAPPORTS SUR LA PERFORMANCE D’EXECUTION 

lls sont decrits a la section 4.5.3.1. Les rapports sur la performance d’execution qui presented un interet particular 
pour le processus MaTtriser les changements comprennent les rapports de disponibilite des ressources, des donnees sur 
I'echeancier et les couts, les rapports de gestion de la valeur acquise (EVM), ainsi que le diagramme du travail accompli 
(«burnup chart») et le diagramme du travail restant (« burndown chart»). 
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4.6.1.4 DEMANDES DE CHANGEMENT 


De nombreux processus produisent des demandes de changement a titre de donnee de sortie. Les demandes 
de changement (decrites a la section 4.3.3.4) peuvent inclure une action corrective, une action preventive, des 
corrections de defauts, ainsi que des mises a jour de documents ou de livrables officiellement maTtrises afin de 
refleter le contenu ou les idees modifies ou supplementaires. Les changements peuvent influer ou non sur les 
references de base du projet. Parfois, seule la performance par rapport a la reference de base est concernee. Les 
decisions relatives a ces changements sont generalement prises par le chef de projet. 

Les demandes de changement qui influent sur les references de base de projet doivent normalement inclure des 
informations sur le cout d'application du changement, les changements apportes aux dates planifiees, les besoins en 
ressources et les risques. Ces changements doivent etre approuves par le comite de maTtrise des changements (le 
cas echeant) et par le client ou le sponsor, a moins qu’ils ne fassent deja partie de ce comite. Seuls les changements 
approuves doivent etre integres a une reference de base mise a jour. 

4.6.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus MaTtriser les 
changements, on peut citer: 

♦ les restrictions legates, telles que les regimentations locales ou nationales ; 

♦ les standards gouvernementaux ou industriels (par exemple, standards de produits, standards de qualite, 
standards de securite et standards de fabrication); 

♦ les exigences et/ou contraintes reglementaires et juridiques ; 

♦ le cadre de gouvernance organisationnelle (un moyen structure d’apporter maTtrise, orientation et coordination 
grace a des personnes, des politiques et des processus, en vue d'atteindre des objectifs organisationnels 
strategies et operationnels); 

♦ les contraintes liees aux achats et aux contrats. 

4.6.1.6 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser les changements, on 
peut citer: 

♦ les procedures de maTtrise des changements, comprenant les regies de changement des standards, des 
politiques, des plans et des procedures de I'organisation ou de tout autre document de projet, ainsi que les 
modalites d'approbation et de validation de ces changements ; 

♦ les procedures d’approbation et d’emission des autorisations de changement; 

♦ la base de connaissance en gestion de la configuration contenant les versions et les references de base pour 
I’ensemble des standards, des politiques et des procedures officiels de I’organisation et de tous les documents 
du projet. 
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4.6.2 MAITRISER LES CHANGEMENTS : OUTILS ET TECHNIQUES 


4.6.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ connaissances techniques du secteur d’activite et du domaine d’interet specifique du projet; 

♦ legislation et regimentations ; 

♦ affaires juridiques et approvisionnement; 

♦ gestion de la configuration ; 

♦ gestion des risques. 

4.6.2.2 OUTILS DE MAITRISE DES CHANGEMENTS 

Afin de faciliter la gestion de la configuration et des changements, on peut utiliser des outils manuels ou automates. 
La martrise de la configuration est centree sur les specifications a la fois des livrables et des processus, alors que la 
maTtrise des changements est centree sur I’identification, la documentation et I'approbation ou le rejet des changements 
apportes aux documents, aux livrables ou aux references de base du projet. 

Le choix de ces outils doit reposer sur les besoins des parties prenantes du projet en tenant compte des considerations 
et/ou des contraintes organisationnelles et environnementales. Ces outils doivent soutenir les activites suivantes de 
gestion de la configuration : 

♦ Identification d’un element de configuration. L’identification et la selection d’un element de configuration 
servent de base a la definition et a la verification de la configuration du produit, a I'etiquetage des produits et des 
documents, a la gestion des changements et au maintien de la responsabilite. 

♦ Enregistrement et communication de I’etat d’un element de configuration. II s'agit des informations liees 
a I’enregistrement et a la communication de chaque element de configuration. 

♦ Verification et audit d’un element de configuration. La verification et les audits de la configuration permettent 
d’assurer que la composition des elements de configuration d’un projet est correcte et que les changements 
correspondants sont enregistres, evalues, approuves, suivis et correctement appliques. Le respect des exigences 
fonctionnelles definies dans la documentation de la configuration est ainsi assure. 
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Ces outils doivent soutenir les activites suivantes de gestion des changements : 

♦ Identification des changements. Identifier et selectionner un changement pour les processus ou les documents 
du projet. 

♦ Documentation des changements. Documenter le changement dans une demande de changement appropriee. 

♦ Definition des changements. Passer en revue les changements, approuver, rejeter, reporter ou prendre toute 
autre decision concernant des changements a apporter aux documents, livrables ou references de base du projet. 

♦ Suivi des changements. Verifier que les changements sont enregistres, evalues, approuves, suivis et leurs 
resultats finaux communiques aux parties prenantes. 

Des outils sont egalement utilises pour gerer les demandes de changement et les decisions qui en resultent. Pour 
que la communication assiste les membres du comite de martrise des changements dans leurs fonctions et diffuse les 
decisions aux parties prenantes concernees, il convient de prendre en consideration d’autres elements. 

4.6.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. Elle est decrite a la section 9.2.2.5. Cette technique est utilisee pour evaluer les 
changements requis et determiner quels changements sont acceptes, rejetes ou doivent etre modifies pour 
finalement etre acceptes. 

♦ Analyse cout-benefice. Elle est decrite a la section 8.1.2.3. Cette analyse permet de determiner si le changement 
requis vaut le cout associe. 

4.6.2.4 PRISE DE DECISION 

Parmi les techniques de prise de decision pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Vote. II est decrit a la section 5.2.2.4. Le vote peut se faire a Punanimite, a la majorite ou a la plurality pour 
decider de I’acceptation, du report ou du rejet de demandes de changement. 

♦ Prise de decision autocratique. Dans le cadre de cette techniques de prise de decision, une personne assume 
la responsabilite de prendre la decision pour I’ensemble du groupe. 

♦ Analyse decisionnelle multicritere. Elle est decrite a la section 8.1.2.4. Cette technique utilise une matrice 
decisionnelle pour offrir une approche analytique systematique et evaluer les changements requis conformement 
a un ensemble de criteres predefinis. 
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4.6.2.5 REUNIONS 


Les reunions de maTtrise des changements sont organisees avec un comite de maTtrise des changements charge de 
satisfaire aux demandes de changement et de les examiner, ainsi que d’approuver, de rejeter ou de reporter les demandes 
de changement. La plupart des changements auront une certaine influence sur la duree, le cout, les ressources ou les 
risques. L'evaluation de I’impact des changements constitue une part essentielle de la reunion. Les reunions permettent 
egalement de proposer et d’etudier des alternatives aux changements demandes. Enfin, la decision est communiquee 
au responsable ou au groupe demandeur. 

Le comite de maTtrise des changements peut egalement passer en revue les activites de gestion de la configuration. 
Les roles et les responsabilites de ces comites sont clairement definis et approuves par les parties prenantes concernees 
et sont documents dans le plan de gestion des changements. Les decisions du comite de maTtrise des changements 
sont documentees et communiquees aux parties prenantes pour information et actions de suivi. 


4.6.3 MAITRISER LES CHANGEMENTS : DONNEES DE SORTIE 

4.6.3.1 DEMANDES DE CHANGEMENT APPROUVEES 

Le chef de projet, le comite de maTtrise des changements ou un membre designe de I’equipe traite les demandes 
de changement (decrites a la section 4.3.3.4), conformement au plan de gestion des changements. Au final, les 
changements peuvent etre approuves, reportes ou rejetes. Les demandes de changement approuvees seront mises 
en oeuvre en appliquant le processus Diriger et gerer le travail du projet. Les demandes de changement reportees ou 
rejetees sont communiquees a la personne ou au groupe demandant le changement. 

L’issue de toutes les demandes de changement est enregistree dans le journal des changements en tant que mise 
a jour du document de projet. 

4.6.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout composant du plan de management du projet officiellement maTtrise peut etre modifie a la suite de ce processus. 
Les changements des references de base ne portent que sur des elements futurs. Les performances passees ne sont pas 
modifiees. L’integrite des references de base et des donnees historiques des performances passees est ainsi respectee. 

4.6.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Tout document du projet officiellement maTtrise peut etre modifie a la suite de ce processus. Un document de projet 
generalement mis a jour a la suite de ce processus est le journal des changements. Ce dernier sert a documenter les 
changements qui ont lieu au cours du projet. 
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4.7 CLORE LE PROJET OU LA PHASE 


Clore le projet ou la phase est le processus de finalisation de toutes les activites d’un projet, d’une phase ou d’un 
contrat. L’interet principal de ce processus est que les informations du projet ou de la phase sont archivees, le travail 
prevu est acheve et les ressources de I'equipe organisationnelle sont liberees afin de mener d'autres projets. Ce 
processus est execute au moins une fois ou a plusieurs moments predefinis durant le projet. Les donnees d’entree, 
les outils, les techniques et les donnees de sortie de ce processus sont represents sur la figure 4-14. La figure 4-15 
represente le diagramme de flux de donnees du processus. 


Clore le projet ou la phase 


Donnees d’entree 


.1 Elaborer la charte du projet 
.2 Elaborer le plan 

de management du projet 

• Tous les composants 
.3 Documents du projet 

• Journaldes hypotheses 

• Base des estimations 

• Journal des changements 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Liste des jalons 

• Communications du projet 

• Mesures de controle 
de la qualite 

• Rapport de qualite 

• Documentation 
des exigences 

• Registre des risques 

• Rapport sur les risques 
.4 Livrables acceptes 

.5 Documents business 

• Business case 

• Plan de gestion 
des benefices 

.6 Accords 
.7 Documents 

d'approvisionnements 
.8 Actifs organisationnels 
V___ ) 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Analyse des donnees 
•Analyse des documents 

• Analyse de regression 

• Analyse de la tendance 

• Analyse des ecarts 
.3 Reunions 

v_y 


Donnees de sortie 


.1 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 
.2 Transfert du produit, 

du service ou du resultat final 
.3 Rapport final 
.4 Mises a jour des actifs 
organisationnels 

V_/ 


Figure 4-14. Clore le projet ou la phase : donnees d’entree, outils, techniques et donnees de sortie 
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Figure 4-15. Clore le projet ou la phase : diagramme de flux de donnees 
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Lors de la cloture du projet, le chef de projet passe en revue le plan de management du projet de fagon a s'assurer 
que tout le travail du projet est acheve et que le projet a atteint ses objectifs. Les activites necessaires a la cloture 
administrative du projet ou de la phase sont notamment les suivantes: 

♦ les actions et les activites necessaires a la satisfaction des criteres d’achevement ou de sortie d’une phase ou 
d’un projet, telles que : 

■ s'assurer que tous les documents et livrables sont a jour et que tous les points a traiter sont resolus, 

■ confirmer la livraison et I’acceptation officielle des livrables par le client, 

■ veiller a la facturation de tous les couts du projet, 

■ clore les comptes du projet, 

■ reaffecter le personnel, 

■ gerer le surplus de ressources materielles, 

■ reaffecter les installations, I’equipement et les autres ressources du projet, 

■ elaborer les rapports finaux du projet, conformement aux politiques organisationnelles; 

♦ les activites relatives a I’execution des accords contractuels applicables au projet ou a la phase du projet, 
telles que : 

■ confirmer I’acceptation formelle du travail du fournisseur, 

■ finaliser les reclamations en suspens, 

■ mettre a jour les registres du projet pour refleter les resultats finaux, 

■ archiver ces informations pour utilisation future; 

♦ les activites necessaires pour: 

■ collecter les donnees du projet ou de la phase, 

■ verifier la reussite ou I'echec du projet, 

■ gerer le partage et le transfer! des connaissances, 

■ identifier les retours d’experience, 

■ archiver les informations du projet pour utilisation future par I’organisation ; 

♦ les actions et les activites necessaires au transfert des produits, des services ou des resultats du projet vers la 
phase suivante, vers la production et/ou vers les operations ; 

♦ recueillir les suggestions d’amelioration ou de mises a jour des politiques et procedures de I’organisation, et les 
envoyer a I’unite organisationnelle concernee; 

♦ mesurer la satisfaction des parties prenantes. 

Le processus Clore le projet ou la phase permet egalement d’etablir les procedures d'examen et de documentation 
des raisons qui ont conduit a annuler un projet avant qu’il ne soit acheve. Pour effectuer cela avec succes, le chef de 
projet doit impliquer toutes les parties prenantes concernees dans le processus. 
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4.7.1 CLORE LE PROJET OU LA PHASE : DONNEES D’ENTREE 


4.7.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet documente les criteres de reussite du projet, les exigences 
d’acceptation et la personne qui validera le projet. 

4.7.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Tous les composants du plan de management du projet constituent des donnees 
d’entree pour ce processus. 

4.7.1.3 DOCUMENTS DU PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment les suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses enregistre toutes les 
hypotheses et contraintes qui ont oriente les specifications techniques, les estimations, I’echeancier et les 
risques, entre autres. 

♦ Base des estimations. Elle est decrite dans les sections 6.4.3.2 et 7.2.3.2. La base des estimations est utilisee 
pour evaluer I’estimation de la duree, du cout, des ressources et de la maTtrise des couts en comparaison avec 
les resultats reels. 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Le journal des changements comprend I'etat de 
toutes les demandes de changement au cours du projet ou de la phase. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter est utilise pour 
verifier qu’il n’y a pas d’evenement en suspens. 

♦ Registre des retours d’experience. II est decrit a la section 4.3.3.1. Les retours d’experience de la phase ou du 
projet seront finalises avant d'etre saisis dans I'archive des retours d’experience. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons indique les dates finales auxquelles les 
jalons du projet ont ete atteints. 

♦ Communications du projet. Elies sont decrites a la section 10.2.3.1. Les communications du projet incluent 
toutes les communications creees au cours du projet. 

♦ Mesures de maTtrise de la qualite. Elies sont decrites a la section 8.3.3.1. Les mesures de maTtrise de la qualite 
documentent les resultats des activites de maTtrise de la qualite et demontrent la conformite avec les exigences 
de qualite. 

♦ Rapports de qualite. Ms sont decrits a la section 8.2.3.1. Les informations presentees dans le rapport de qualite 
peuvent inclure tous les points a traiter en matiere d’assurance qualite geres ou transmis par I’equipe, les 
recommandations d’amelioration et la synthese des conclusions du processus MaTtriser la qualite. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences est utilisee 
pour demontrer la conformite au perimetre du projet. 
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♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques fournit des informations sur les 
risques qui se sont presenters au cours du projet. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques donne des informations sur 
I’etat des risques. II est utilise pour verifier qu’il n’y a plus aucun risque a la fin du projet. 

4.7.1.4 LIVRABLES ACCEPTES 

Ms sont decrits a la section 5.5.3.1. Les livrables acceptes peuvent inclure les specifications de produit, les regus 
de livraison et les documents de performance d’execution approuves. Des livrables partiels ou intermediates peuvent 
egalement etre inclus dans les projets par phases, ou pour les projets annules. 

4.7.1.5 DOCUMENTS BUSINESS 

Ms sont decrits a la section 1.2.6. Les documents business comprennent notamment les elements suivants : 

♦ Business Case. Le business case documente les besoins de I'organisation et I’analyse cout-benefice justifiant 
le projet. 

♦ Plan de gestion des benefices. Le plan de gestion des benefices decrit les benefices cibles du projet. 

Le business case permet de determiner si les resultats attendus de I'etude de faisabilite economique utilisee pour 
justifier le projet ont ete atteints. Le plan de gestion des benefices sert a evaluer si les benefices du projet ont ete 
obtenus com me prevu. 

4.7.1.6 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les exigences relatives a la cloture formelle des approvisionnements sont 
habituellement definies dans les conditions generates du contrat et sont comprises dans le plan de gestion des 
approvisionnements. Un projet complexe peut impliquer la gestion simultanee ou sequentielle de plusieurs contrats. 

4.7.1.7 DOCUMENTS D’APPROVISIONNEMENTS 

Ms sont decrits a la section 12.3.1.4. Pour clore le contrat, tous les documents d’approvisionnements sont collectes, 
indexes et classes. Les informations du contrat relatives a I’echeancier, au perimetre, a la qualite et a la performance 
des couts, ainsi que la documentation des changements apportes au contrat, les enregistrements de paiement et 
les resultats d’inspection sont catalogues. A la cloture du projet, les plans/schemas d’execution ou les documents 
d’elaboration, les manuels, les guides de depannage et les autres documents techniques doivent egalement etre 
considers comme faisant partie des documents d’approvisionnements. Ces informations peuvent etre utilisees pour 
les retours d’experience et comme base devaluation des fournisseurs pour de futurs contrats. 
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4.7.1.8 ACTIFS ORGANISATION ELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Clore le projet ou la phase, on 
peut citer: 

♦ les directives ou les exigences de cloture du projet ou de la phase (les retours d’experience, les verifications finales 
du projet, les evaluations du projet, les validations de produit, les criteres d’acceptation, la cloture du contrat, la 
reallocation des ressources, les appreciations des performances de I’equipe et le transfert de connaissances); 

♦ la base de connaissance en gestion de la configuration contenant les versions et les references de base pour 
I’ensemble des standards, des politiques et des procedures officiels de I’organisation et de tous les documents 
du projet. 

4.7.2 CLORE LE PROJET OU LA PHASE : OUTILS ET TECHNIQUES 

4.7.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ maTtrise du management; 

♦ audit; 

♦ affaires juridiques et approvisionnement; 

♦ legislation et regimentations. 

4.7.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse de documents. Elle est decrite a la section 5.2.2.3. L'evaluation des documents disponibles permet 
d’identifier les retours d’experience et le partage des connaissances pour les futurs projets et la consolidation 
des actifs organisationnels. 

♦ Analyse de regression. Cette technique analyse les relations entre les differentes variables du projet ayant 
contribue aux resultats du projet en vue d'ameliorer la performance des futurs projets. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5.2.2. L'analyse de la tendance peut etre utilisee 
pour valider les modeles utilises au sein de I’organisation et appliquer des rectifications dans le cadre des 
futurs projets. 

♦ Analyse des ecarts. Elle est decrite a la section 4.5.2.2. L'analyse des ecarts peut etre utilisee pour ameliorer 
les metriques de I'organisation en comparant ce qui etait initialement prevu et le resultat final. 
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47.2.3 REUNIONS 

Les reunions sont utilisees pour confirmer que les livrables ont ete acceptes, valider que les criteres de sortie ont 
ete satisfaits, formaliser I'execution des contrats, evaluer la satisfaction des parties prenantes, rassembler les retours 
d’experience, transferer les connaissances et les informations tirees du projet, puis celebrer la reussite. Parmi les 
participants a ces reunions, on trouve des membres de I’equipe projet et d’autres parties prenantes impliquees dans le 
projet ou affectees par celui-ci. Les reunions peuvent etre en face a face, virtuelles, formelles ou informelles. II existe 
differents types de reunions tels que les reunions de rapport de cloture, les reunions de synthese avec les clients, les 
reunions concernant les retours d’experience et les reunions de celebration. 


4.7.3 CLORE LE PROJET OU LA PHASE : DONNEES DE SORTIE 
4.7.3.1 MISES A JOUR DES DOCUMENTS DU PROJET 

Tous les documents du projet peuvent etre mis a jour et marques comme etant des versions finales a la suite de la 
cloture du projet. Le registre des retours d’experience, qui est finalise pour inclure les informations finales concernant 
la cloture du projet ou de la phase, presente un interet particulier. Le registre des retours d’experience finaux peut 
contenir des informations sur la gestion des benefices, I’exactitude du business case, les cycles de vie du projet, la 
gestion des points a traiter et des risques, I'engagement des parties prenantes et d’autres processus de management 
de projet. 

47.3.2 TRANSFERT DU PRODUIT, DU SERVICE OU DU RESULTAT FINAL 

Un produit, un service ou un resultat, une fois livre par le projet, peut etre remis a un autre groupe ou une autre 
organisation qui I’utilisera, en assurera la maintenance et le support tout au long de son cycle de vie. 

Cette donnee de sortie se rapporte au transfert du produit, du service ou du resultat final (ou, dans le cas de la cloture 
d’une phase, du produit, du service ou du resultat intermediate), pour la production duquel le projet a ete autorise, d’une 
equipe a une autre. 

47.3.3 RAPPORT FINAL 

Le rapport final donne un resume de la performance du projet. II peut notamment inclure : 

♦ une breve description du projet ou de la phase; 

♦ les objectifs du perimetre, les criteres utilises pour evaluer le perimetre et des elements demontrant que les 
criteres d’execution ont ete satisfaits ; 

♦ les objectifs de qualite, les criteres utilises pour evaluer la qualite du projet et du produit, ainsi que les dates de 
verification et de livraison reelle des jalons, et les raisons des ecarts ; 

♦ les objectifs de cout, y compris la fourchette des couts acceptables, les couts reels et les raisons des ecarts; 

♦ une synthese des informations concernant la validation du produit, service ou resultat final; 


127 



♦ les objectifs de I’echeancier, y compris I’obtention ou non des benefices que le projet devait produire. Si les 
benefices ne sont pas obtenus a la cloture du projet, indiquer le niveau des benefices atteint et les estimations 
quant a I’obtention future des benefices; 

♦ une synthese de la fagon dont le produit, le service ou le resultat final a permis de repondre aux besoins de 
I’organisation dans le cadre du business plan. Si les besoins de I’organisation ne sont pas satisfaits a la cloture 
du projet, indiquer dans quelle mesure ils ont ete satisfaits et quand ils seront satisfaits; 

♦ une synthese des risques ou des points a traiter rencontres au cours du projet et la methode de traitement. 

47.3.4 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Certains actifs organisationnels sont mis a jour, en particulier les suivants : 

♦ Documents du projet. II s'agit des documents relatifs aux activites du projet (par exemple, le plan de management 
du projet, le perimetre, I’echeancier des couts, les calendriers du projet) et des documents lies a la gestion des 
changements. 

♦ Documents de reference et documents operationnels. II s'agit des documents requis par une organisation 
pour entretenir, exploiter et soutenir le produit ou le service livre par le projet. II peut s’agir de nouveaux documents 
ou de mises a jour de documents existants. 

♦ Documents de cloture du projet ou de la phase. II s’agit des documents de cloture du projet ou de la phase. Ces 
documents comprennent la documentation formalisant I’achevement du projet ou de la phase et le transfert des 
livrables acheves du projet ou de la phase a un groupe d’operations ou a la phase suivante. Lors de la cloture du 
projet, le chef de projet passe en revue la documentation de la phase precedente, la documentation d’acceptation 
du client provenant du processus Valider le perimetre (voir la section 5.5) et I'accord (le cas echeant), afin de 
s'assurer que toutes les exigences du projet sont satisfaites avant de finaliser la cloture du projet. Si un projet 
cesse avant d’etre acheve, la documentation formelle en indique les raisons et formalise les procedures de 
transfert des livrables finis et non finis de ce projet. 

♦ Archive des retours d’experience. Les retours d’experience et les connaissances acquises tout au long du 
projet sont transfers dans I'archive des retours d’experience pour utilisation par les projets futurs. 
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GESTION DU PERIMETRE DU PROJET 

La gestion du perimetre du projet inclut les processus requis pour s'assurer que tout le travail requis par le projet, 
et seulement le travail requis, est effectue pour mener le projet a son terme avec succes. La gestion du perimetre du 
projet porte essentiellement sur la definition et la maitrise de ce qui est inclus dans le projet et de ce qui en est exclu. 

Les processus de gestion du perimetre du projet sont: 

5.1 Planifier la gestion du perimetre —Ce processus consiste a creer un plan de gestion du perimetre qui documente 
la fagon dont le perimetre du projet et le contenu du produit seront definis, valides et maTtrises. 

5.2 Recueillir les exigences —Ce processus consiste a determiner, a documenter et a gerer les besoins et les 
exigences des parties prenantes pour atteindre les objectifs du projet. 

5.3 Definir le perimetre —Ce processus consiste a elaborer une description detaillee du projet et du produit. 

5.4 Creer le WBS —Ce processus consiste a subdiviser les livrables et le travail du projet en composants plus petits 
et plus faciles a gerer. 

5.5 Valider le perimetre —Ce processus consiste a formaliser I'acceptation des livrables du projet termines. 

5.6 Maltriser le perimetre —Ce processus consiste a maTtriser I’avancement du projet, a verifier le perimetre du 
produit et a integrer les changements affectant la reference de base du perimetre. 

La figure 5-1 donne une vue d’ensemble des processus de gestion du perimetre du projet. Les processus de gestion 
du perimetre du projet sont presentes comme des processus distincts ayant des interfaces clairement definies, alors 
que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre completement 
detaillees dans le Guide PMBOK®. 
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Vue d’ensemble de la gestion 
du perimetre du projet 


5.1 Planifier la gestion 
du perimetre et du contenu 



5.2 Recueillir 
les exigences 


.1 Donnees d'entree 

.1 Elaborer la charte du projet 
.2 Elaborer le plan 

de management du projet 
.3 Documents du projet 
.4 Documents business 
.5 Accords 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 
.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Prise de decision 
.5 Representation des donnees 
.6 Competences 

interpersonnelles et d'equipe 
.7 Schema contextuel 
.8 Prototypes 
.3 Donnees de sortie 

.1 Documentation des exigences 
.2 Matrice detragabilite 
des exigences 

V___/ 



5.3 Definir le contenu 


.1 Donnees d'entree 
.1 Elaborer la charte 
du projet 

.2 Elaborer le plan 
de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 
.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Prise de decision 
.4 Competences 
interpersonnelles et d'equipe 
.5 Analyse du produit 
.3 Donnees de sortie 

.1 Enonce du perimetre du projet 
.2 Mises a jour des documents 
du projet 

V _/ 


5.6 Maitriser le perimetre 


.1 Donnees d'entree 
.1 Elaborer le plan 

de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 

.4 Actifs organisationnels 
.2 Outils ettechniques 
.1 Analyse des donnees 
.3 Donnees de sortie 
.1 Information sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

V___/ 


Figure 5-1. Vue d’ensemble de la gestion du perimetre du projet 
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PRINCIPAUX CONCEPTS DE LA GESTION DU PERIMETRE DU PROJET 

Dans le contexte d’un projet, le terme« perimetre»peut se rapporter au : 

♦ Contenu du produit. Caracteristiques etfonctions qui caracterisent un produit, un service ou un resultat. 

♦ Perimetre du projet. C’est le travail qui doit etre realise pour livrer un produit, un service ou un resultat possedant 
les caracteristiques et les fonctions specifies. L'expression « perimetre du projet» est parfois assimilee a 
«contenu du produit». 

Le type de cycle de vie du projet peut varier entre une approche predictive jusqu’a une approche adaptative ou agile. 
Dans le cas d’un cycle de vie predictif, les livrables sont definis en debut de projet, ettous les changements apportes au 
niveau du perimetre sont controles progressivement. Dans le cas d’un cycle de vie adaptatif ou agile, les livrables sont 
elabores en de multiples iterations au cours desquelles un perimetre est detaille au debut de ladite iteration. 

Les projets aux cycles de vie adaptatifs sont destines a repondre a de grands degres de changement et exigent une 
participation continue de la part des parties prenantes. Le perimetre global d’un projet adaptatif sera decompose en un 
ensemble d’exigences et de travail a effectuer, parfois appele besoins en attente («backlog») du produit. Au debut d’une 
iteration, I'equipe travaillera a determiner combien des elements de la priorite la plus grande se trouvant sur le backlog 
pourront etre livres au cours de la prochaine iteration. Les trois processus Recueillir les exigences, Definir le perimetre 
et Creer le WBS sont repetes pour chaque iteration. En revanche, dans le cas d’un projet predictif, ces processus sont 
executes en debut de projet puis mis a jour, si necessaire, a I’aide du processus de maTtrise integree des changements. 

Pour le cycle de vie adaptatif ou agile, les representants du sponsor et du client doivent etre constamment impliques 
dans le projet afin de fournir un retour d’information sur les livrables au fur et a mesure qu’ils sont crees et pour assurer 
que le backlog reflete bien leurs besoins actuels. Les deux processus Valider le perimetre et MaTtriser le perimetre 
sont repetes pour chaque iteration. En revanche, dans le cas d’un projet predictif, le processus Valider le perimetre est 
reserve aux livrables ou revues de phase, tandis que le processus MaTtriser le perimetre est execute de fagon continue. 

Pour les projets predictifs, la reference de base du perimetre du projet est la version approuvee de I’enonce du 
perimetre du projet, de I’organigramme des travaux du projet (WBS) et du dictionnaire du WBS associe. Une reference de 
base ne peut etre modifiee qu'au travers des procedures formelles de maTtrise des changements et est utilisee comme 
base de comparaison au cours de I'execution des processus Valider le perimetre, MaTtriser le perimetre ainsi qu'au 
cours d’autres processus de maTtrise. Les projets aux cycles de vie adaptatifs s’appuient sur les listes des besoins en 
attente ou « backlogs », notamment les exigences du produit et les scenarii d’utilisation (user stories), afin de refleter 
leurs besoins actuels. 

L'achevement du perimetre du projet se mesure en fonction du plan de management du projet, alors que I'achevement 
du contenu du produit se mesure en fonction des exigences du produit. Le terme«exigence» designe une condition ou 
une capacite requise pour un produit, un service ou un resultat afin de satisfaire un accord ou toute autre specification 
imposee officiellement. 

Valider le perimetre est le processus qui consiste a formaliser I'acceptation des livrables du projet termines. Les 
livrables verifies obtenus a partir du processus MaTtriser la qualite represented une donnee d’entree du processus 
Valider le perimetre. Les livrables acceptes constituent I’une des donnees de sortie du processus Valider le perimetre. 
Ms sont formellement acceptes et approuves par les parties prenantes autorisees. Par consequent, les parties prenantes 
doivent participer a la planification assez tot, parfois meme a I’initialisation, et fournir des donnees d’entree sur la qualite 
des livrables de maniere a ce que le processus MaTtriser la qualite puisse evaluer les performances et recommander les 
changements necessaires. 
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TENDANCES ET PRATIQUES EMERGENTES EN GESTION DU PERIMETRE DU PROJET 


Les exigences sont, depuis toujours, au coeur du management de projet. Elies ne cessent d’attirer I’attention de la 
profession. A mesure que I'environnement mondial devient plus complexe, les organisations commencent a comprendre 
comment utiliser la Business Analysis pour developper un avantage concurrentiel grace a la definition, la gestion et la 
maTtrise des activites liees aux exigences. Les activites de la Business Analysis peuvent demarrer avant le lancement 
du projet et la designation d’un chef de projet. Selon Requirements Management: A Practice Guide [14], le processus 
de gestion des exigences commence par une evaluation des besoins, pouvant etre initialisee lors de la planification du 
portefeuille ou du programme ou bien dans le cadre d’un projet distinct. 

La collecte, la documentation et la gestion des exigences des parties prenantes interviennent lors des processus de 
gestion du perimetre du projet. Les tendances et les pratiques emergentes de la gestion du perimetre du projet incluent, 
en particulier, la collaboration avec des professionnels de la Business Analysis pour: 

♦ identifier les problematiques et les besoins business ; 

♦ identifier et recommander des solutions viables en vue de satisfaire a ces besoins ; 

♦ collecter, documenter et gerer les exigences des parties prenantes afin d’atteindre les objectifs du projet et les 
objectifs business; 

♦ faciliter la bonne mise en oeuvre du produit, du service ou du resultat final du programme ou du projet [7], 

La Business Analysis se termine par la cloture des exigences, qui effectue la transition du produit, du service ou du 
resultat vers les beneficiaires afin de mesurer, de maitriser, de produire et de maintenir les benefices au fil du temps. 

La tache de la Business Analysis devrait etre confiee aux ressources disposant de competences et d’expertise 
business suffisantes. Si un business analyst est affecte a un projet, les activites liees aux exigences relevent de son role. 
Le chef de projet doit s'assurer que le travail relatif aux exigences est pris en compte au niveau du plan de management 
du projet et que les activites liees aux exigences respectent les delais, le budget et les livrables. 

Le chef de projet et le business analyst doivent travailler en etroite collaboration. Les chances de reussite du 
projet sont d’autant plus grandes si le chef de projet et le business analyst comprennent parfaitement les roles et les 
responsabilites de chacun afin d’atteindre les objectifs du projet. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 


Chaque projet etant unique, le chef de projet devra adapter I’application de chacun des processus de gestion du 
perimetre du projet. Parmi les considerations relatives a I'adaptation, on peut citer les elements suivants : 

♦ Gestion des connaissances et des exigences. L’organisation dispose-t-elle de systemes de gestion des 
exigences et des connaissances formels ou informels ? Quelles directives le chef de projet devrait-il etablir pour 
que les exigences puissent etre reutilisees ulterieurement ? 

♦ Validation et maitrise. L'organisation a-t-elle etabli des politiques internes, des procedures et des directives de 
validation et de maitrise formelles ou informelles ? 

♦ Approche de developpement. L’organisation utilise-t-elle des approches agiles pour manager les projets ? 
L’approche de developpement est-elle iterative ou incrementielle ? A-t-on fait appel a une approche predictive ? 
Une approche hybride pourrait-elle etre efficace ? 

♦ Stability des exigences. Certains domaines du projet presentent-ils des exigences instables ? Faut-il utiliser 
des techniques lean, agiles ou d’autres techniques adaptatives pour que les exigences instables deviennent 
stables et soient bien definies ? 

♦ Gouvernance. L'organisation a-t-elle etabli des politiques internes, des procedures et des directives de 
gouvernance et d’audit formelles ou informelles ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Pour les projets qui presentent des exigences changeantes, un risque eleve ou une grande incertitude, le perimetre 
est souvent mal compris au debut ou evolue au cours du projet. Les methodes agiles passent moins de temps a definir le 
perimetre au cours des premieres phases du projet pour se concentrer davantage sur I’etablissement de son processus 
de decouverte et d’amelioration continues. Bon nombre d’environnements aux exigences nouvelles se caracterisent 
souvent par un ecart entre les exigences business reelles et les exigences business initialement prevues. Les methodes 
agiles realisent des prototypes, les passent en revue, puis produisent des versions afin d’affiner les exigences. Le 
perimetre est done defini puis redefini au cours du projet. Dans le cas des approches agiles, les exigences constituent 
le backlog. 
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5.1 PLANIFIER LA GESTION DU PERIMETRE 


Planifier la gestion du perimetre est le processus qui consiste a creer un plan de gestion du perimetre qui documente 
la fagon dont le perimetre du projet et le contenu du produit sera defini, valide et martrise. L'interet principal de ce 
processus est qu'il fournit les directives et les orientations de gestion du perimetre tout au long du projet. Ce processus 
est execute au moins une fois ou a plusieurs moments predefinis durant le projet. Les donnees d’entree, les outils, les 
techniques et les donnees de sortie de ce processus sont represents sur la figure 5-2. La figure 5-3 represente le 
diagramme de flux de donnees de ce processus. 


Planifier la gestion du perimetre et du contenu 


Donnees d’entree 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion de la qualite 

• Description du cycle de vie 
du projet 

• Approche de developpement 
.3 Facteurs environnementaux 

de I'organisation 
.4 Actifs organisationnels 

V___/ 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Analyse des donnees 
•Analyse des alternatives 
.3 Reunions 

\ _ / 


Donnees de sortie 


1 Plan de gestion du perimetre 
et du contenu 

.2 Plan de gestion des exigences 

V___ 


Figure 5-2. Planifier la gestion du perimetre: donnees d’entree, outils, techniques et donnees de sortie 



• Facteurs environnementaux de I’organisation 

• Actifs organisationnels 


Figure 5-3. Planifier la gestion du perimetre: diagramme de flux de donnees 
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Le plan de gestion du perimetre est un composant du plan de management du projet ou du programme qui decrit la 
maniere dont le perimetre sera defini, developpe, maTtrise et valide. L'elaboration du plan de gestion du perimetre et le 
developpement des details du perimetre du projet commencent par I’analyse des informations contenues dans la charte 
du projet (voir la section 4.1.3.1), de la derniere version des plans subsidiaires approuves du plan de management du 
projet (voir la section 4.2.3.1), des donnees historiques contenues dans les actifs organisationnels (voir la section 2.3) 
et de tout autre facteur environnemental de I'organisation pertinent (voir la section 2.2). 


5.1.1 PLANIFIER LA GESTION DU PERIMETRE : DONNEES D’ENTREE 

5.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet documente I’objet du projet, la description generate du projet, 
les hypotheses, les contraintes et les exigences que le projet est suppose satisfaire. 

5.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. La gestion du perimetre du projet et du contenu 
du produit peut etre influencee par la fagon dont la politique qualite, les methodologies et les standards de 
I’organisation sont appliques au projet. 

♦ Description du cycle de vie du projet. Le cycle de vie d’un projet determine la serie de phases que celui-ci 
traverse, depuis sa creation jusqu’a sa cloture. 

♦ Approche de developpement. L'approche de developpement definit si une approche de developpement 
waterfall, iterative, adaptative, agile ou hybride sera employee. 

5.1.1.3 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion du perimetre, on peut citer: 

♦ la culture de I'organisation ; 

♦ I’infrastructure; 

♦ I’administration du personnel; 

♦ les conditions du marche. 
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5.1.1.4 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion du perimetre, 
on peut citer: 

♦ les politiques et les procedures ; 

♦ les donnees historiques et les registres des retours d’experience. 

5.1.2 PLANIFIER LA GESTION DU PERIMETRE : OUTILS ET TECHNIQUES 

5.1.2.1 JUGEMENTA DIRE D’EXPERT 

II convient de faire appel a la competence decrite a la section 4.1.2.1 de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ les projets anterieurs similaires ; 

♦ les informations du secteur, de la discipline et du domaine d’application. 

5.1.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figure notamment I’analyse 
des alternatives. Differentes fagons de recueillir les exigences, d’elaborer le perimetre du projet et le contenu du 
produit, de creer le produit, de valider le perimetre ou le contenu et de le maitriser sont evaluees. 

5.1.2.3 REUNIONS 

Les equipes projet peuvent prendre part a des reunions de planification pour elaborer le plan de gestion du 
perimetre. Les participants peuvent inclure le chef de projet, le sponsor du projet, des membres selectionnes de 
I'equipe projet, d’autres parties prenantes choisies, toute personne ayant la responsabilite de gerer un des processus 
de gestion du perimetre, ainsi que d’autres personnes, en fonction des besoins. 
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5.1.3 PLANIFIER LA GESTION DU PERIMETRE : DONNEES DE SORTIE 


5.1.3.1 PLAN DE GESTION DU PERIMETRE 

Le plan de gestion du perimetre est un composant du plan de management du projet qui decrit comment le perimetre 
sera defini, developpe, martrise et valide. Les composants du plan de gestion du perimetre comprennent: 

♦ le processus d’elaboration d’un enonce du perimetre du projet; 

♦ le processus de creation du WBS a partir de renonce detaille du perimetre du projet; 

♦ le processus qui etablit la maniere dont la reference de base du perimetre sera approuvee et conservee ; 

♦ le processus qui consiste a specifier comment sera obtenue I'acceptation formelle des livrables acheves du projet. 

Selon les besoins du projet, le plan de gestion du perimetre peut etre formel ou informel, tres detaille ou formule 
de maniere generate. 

5.1.3.2 PLAN DE GESTION DES EXIGENCES 

Le plan de gestion des exigences est un composant du plan de management du projet qui decrit la maniere dont les 
exigences du projet et du produit seront analysees, documentees et gerees. Selon Business Analysis for Practitioners: 
A Practice Guide [7], certaines organisations I’appelle« plan de Business Analysis ». Parmi les composants du plan de 
gestion des exigences, on peut citer, entre autres : 

♦ la maniere dont seront planifiees, suivies et rapportees les activites relatives aux exigences; 

♦ les activites de gestion de la configuration, telles que la fagon dont les changements seront inities, la fagon 
dont les impacts seront analyses, traces, suivis et rapportes, ainsi que les niveaux d’autorisation requis pour 
approuver ces changements; 

♦ les processus de hierarchisation des exigences ; 

♦ les metriques qui seront utilisees et la justification de leur utilisation ; 

♦ la structure de la tragabilite indiquant les attributs des exigences qui seront pris en compte dans la matrice 
de tragabilite. 
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5.2 RECUEILLIR LES EXIGENCES 

Recueillir les exigences est le processus qui consiste a determiner, a documenter et a gerer les besoins et les 
exigences des parties prenantes, dans le but d’atteindre les objectifs du projet. L’interet principal de ce processus est 
qu’il sert de base a la definition et a la gestion du contenu du produit et du perimetre du projet. Ce processus est execute 
au moins une fois ou a plusieurs moments predefinis durant le projet. Les donnees d’entree, les outils, les techniques 
et les donnees de sortie de ce processus sont represents sur la figure 5-4. La figure 5-5 represente le diagramme de 
flux de donnees de ce processus. 


Recueillir les exigences 


Donnees d’entree 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion 
des exigences 

• Plan d'engagement 
des parties prenantes 

.3 Documents du projet 

• Journal des hypotheses 

• Registre des retours 
d'experience 

• Registre des parties 
prenantes 

.4 Documents business 

• Business case 
.5 Accords 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 

V___7 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Collecte des donnees 

• Brainstorming 

• Entretiens 

• Groupes de discussion 

• Questionnaires et enquetes 

• Benchmarking 

.3 Analyse des donnees 

• Analyse des documents 
.4 Prise de decision 

• Vote 

• Analyse decisionnelle 
multicritere 

.5 Representation des donnees 

• Diagrammes d'affinite 

• Mind map 

.6 Competences 

interpersonnelles et d'equipe 

• Technique du groupe 
nominal 

• Observation et discussion 

• Facilitation 

.7 Schema contextuel 
.8 Prototypes 

V___/ 


Donnees de sortie 


.1 Documentation des exigences 
.2 Matrice de tragabilite 
des exigences 

v_._y 


Figure 5-4. Recueillir les exigences: donnees d’entree, outils, techniques et donnees de sortie 
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Documents 
du projet 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 5-5. Recueillir les exigences: diagramme de flux de donnees 
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Le Guide PMBOK® n’aborde pas precisement les exigences du produit etant donne qu'elles sont specifiques au 
secteur. II convient de noter que le Business Analysis for Practitioners: A Practice Guide [7] contient des informations 
plus detaillees sur les exigences du produit. La reussite du projet est directement fonction de I’implication active des 
parties prenantes dans la decouverte et la decomposition des besoins en exigences du projet et du produit, d’une part, et 
du soin apporte a la determination, a la documentation et a la gestion des exigences du produit, du service ou du resultat 
du projet, d’autre part. Les exigences incluent les conditions ou les capacites requises pour un produit, un service ou un 
resultat afin de satisfaire un accord ou toute autre specification imposee officiellement. Les exigences comprennent les 
attentes et les besoins, quantifies et documents, du sponsor, du client et des autres parties prenantes. Ces exigences 
doivent etre recueillies, analysees et enregistrees d’une maniere suffisamment detaillee pour etre inserees dans la 
reference de base du perimetre et pouvoir etre mesurees des le debut de I'execution du projet. Les exigences constituent 
la base du WBS. Les planifications du cout, de I'echeancier et de la qualite ainsi que les approvisionnements sont tous 
bases sur ces exigences. 


5.2.1 RECUEILUR LES EXIGENCES : DONNEES D’ENTREE 

5.2.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet documente la description generate du projet et les exigences 
generates qui seront utilisees pour elaborer des exigences detaillees. 

5.2.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre contient des 
informations sur la definition et I’elaboration du perimetre du projet. 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences contient des 
informations sur la collecte, I'analyse et la documentation des exigences du projet. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des 
parties prenantes est utilise pour comprendre les exigences en communication des parties prenantes et leur 
niveau d’implication pour les evaluer et les adapter au niveau de participation des parties prenantes aux activites 
relatives aux exigences. 
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5.2.1.3 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses identifie les hypotheses 
relatives au produit, au projet, a I’environnement, aux parties prenantes et aux autres facteurs qui peuvent avoir 
une influence sur les exigences. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience permet 
de fournir des informations sur les meilleures techniques de recueil des exigences, notamment pour les projets 
qui utilisent une methodologie de developpement de produit iterative ou adaptative. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes permet 
d’identifier les parties prenantes susceptibles d'apporter des informations sur les exigences. II decrit egalement 
les exigences et les attentes des parties prenantes vis-a-vis du projet. 

5.2.1.4 DOCUMENTS BUSINESS 

Ms sont decrits a la section 1.2.6. Parmi les documents business qui peuvent avoir une influence sur le processus 
Recueillir les exigences, figure le business case, qui decrit les criteres requis, souhaites et facultatifs visant a repondre 
aux besoins de I'organisation. 

5.2.1.5 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les accords peuvent contenir les exigences du projet et du produit. 

5.2.1.6 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Recueillir les 
exigences, on peut citer: 

♦ la culture de I’organisation ; 

♦ I’infrastructure; 

♦ I’administration du personnel; 

♦ les conditions du marche. 

5.2.1.7 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Recueillir les exigences, on 
peut citer: 

♦ les politiques et les procedures ; 

♦ les donnees historiques et I’archive des retours d'experience avec des informations de projets anterieurs. 
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5.2.2 RECUEILUR LES EXIGENCES : OUTILS ET TECHNIQUES 


5.2.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ Business Analysis; 

♦ le recueil des exigences ; 

♦ (’analyse des exigences ; 

♦ la documentation des exigences ; 

♦ les exigences dans des projets anterieurs similaires; 

♦ les techniques de representation graphique ; 

♦ la facilitation; 

♦ la gestion des conflits. 

5.2.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Brainstorming. II est decrit a la section 4.1.2.2. Le brainstorming est une technique qui facilite la production et 
le recueil de nombreuses idees sur les exigences du projet et du produit. 

♦ Entretiens. Un entretien est une approche formelle ou informelle permettant d’obtenir des informations aupres 
des parties prenantes par un dialogue direct. II est habituellement conduit en posant des questions preparees ou 
spontanees et en documentant les reponses. Les entretiens sont souvent conduits a deux entre un interviewer et 
un interview^, mais peuvent egalement impliquer plusieurs interviewers et plusieurs interviewes. Interviewer des 
participants de projet experiments, des sponsors mais aussi d’autres responsables et experts en la matiere peut 
aider a identifier et a definir les caracteristiques et les fonctions des livrables desirables du produit. Les entretiens 
sont egalement utiles pour obtenir des informations confidentielles. 

♦ Groupes de discussion. Les groupes de discussion rassemblent les parties prenantes prequalifiees et les experts 
du domaine concerne, dans le but de connaTtre leurs attentes et leurs reactions face au produit, au service ou au 
resultat propose. Un moderates qualifier conduit, au sein du groupe, une discussion interactive de nature plus 
conversationnelle qu’un entretien a deux. 
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♦ Questionnaires et enquetes. Les questionnaires et les enquetes sont des ensembles de questions ecrites qui 
permettent de recueillir rapidement des informations a partir des reponses d’un grand nombre de personnes. 
Les questionnaires et les enquetes conviennent surtout dans le cas de groupes heterogenes, lorsqu’un resultat 
rapide est necessaire, que les individus sont geographiquement disperses et qu’une analyse statistique pourrait 
etre applicable. 

♦ Benchmarking. II est decrit a la section 8.1.2.2. Le benchmarking consiste a comparer les produits, les 
processus et les pratiques reels ou planifies a ceux d’organisations comparables, dans le but d'identifier les 
bonnes pratiques, de trouver des idees d’amelioration et de fournir une base pour mesurer la performance. Les 
organisations comparees au cours de I’etude peuvent etre de type interne ou externe. 

5.2.2.3 ANALYSE DES DONNEES 

Elle est decrite a la section 4.5.2.2. Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce 
processus figure notamment I'analyse de document. L'analyse de document consiste a examiner et a evaluer toute 
information documentee pertinente. Dans le cadre de ce processus, cette technique est utilisee pour collecter des 
exigences, en analysant la documentation existante et en identifiant les informations correspondant a des exigences. II 
existe une grande variete de documents qui peuvent etre analyses pour contribuer a collecter des exigences pertinentes. 
Parmi les exemples de documents qui peuvent etre analyses, on peut citer, entre autres: 

♦ les accords; 

♦ les business plans; 

♦ la documentation de processus ou d’interfaces business ; 

♦ les referentiels de regies administratives; 

♦ les processus de flux courants ; 

♦ la documentation marketing ; 

♦ le registre des problemes ou des points a traiter; 

♦ les politiques internes et les procedures; 

♦ la documentation reglementaire, telle que les lois, les codes ou les ordonnances ; 

♦ les appels d’offres ; 

♦ les scenarii d’utilisation. 
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5.2.2.4 PRISE DE DECISION 


Parmi les techniques de prise de decision qui peuvent etre utilisees pour le processus Recueillir les exigences 
figurent notamment les elements suivants: 

♦ Vote. Le vote est une technique de prise de decision collective et un processus devaluation de possibilites 
multiples dont on attend comme resultat la decision d’entreprendre de futures actions. Ces techniques peuvent 
etre utilisees pour developper, classifier et classer par ordre de priorite les exigences du produit. Parmi les 
exemples de techniques de vote figurent, entre autres : 

■ Unanimite. Decision selon les termes de laquelle tous les participants approuvent une ligne d’action unique. 

■ Majorite. Decision a laquelle on parvient avec I’accord de plus de la moitie des membres du groupe. Le fait 
d’avoir un groupe qui compte un nombre de participants impair peut permettre d’assurer la prise d’une 
decision specifique au lieu de se terminer par un partage des voix. 

■ Pluralite. La decision revient au bloc le plus important du groupe, meme si la majorite n’est pas atteinte. Cette 
methode est generalement utilisee lorsque le nombre d’options offertes est superieur a deux. 

♦ Prise de decision autocratique. Dans cette methode, une seule personne assume la responsabilite de prendre 
la decision au nom du groupe. 

♦ Analyse decisionnelle multicritere. Cette technique fait appel a une matrice de decision visant a fournir une 
approche analytique systematique, afin d'etablir des criteres, tels que les niveaux de risque, I'incertitude et la 
valorisation, pour evaluer et classer de nombreuses idees. 

5.2.2.5 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Diagrammes d’affinite. Les diagrammes d’affinite permettent de grouper des idees afin de les passer en revue 
et de les analyser. 

♦ Mind map. Les mind maps permettent de consolider les idees emises lors de seances individuelles de 
brainstorming sur une carte unique de fagon a faire ressortir les points communs et les differences ainsi qu'a 
produire de nouvelles idees. 

5.2.2.6 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Elies sont decrites a la section 4.1.2.3. Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees 
pour ce processus figurent notamment les elements suivants : 

■ Technique du groupe nominal. La technique du groupe nominal renforce celle du brainstorming par la 
conduite d’un vote destine a classer les idees les plus utiles. Ces idees sont ensuite soumises a de nouvelles 
seances de brainstorming ou classees par ordre de priorite. La technique du groupe nominal est une forme 
structure de brainstorming en quatre etapes : 
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■ Une question ou un probleme est pose au groupe. Chaque personne reflechit en silence et note ses idees 
par ecrit. 

■ Le moderates ecrit les idees sur un tableau jusqu'a ce que toutes les idees soient repertoriees. 

■ Chaque idee notee est examinee jusqu'a ce que tous les membres du groupe I’aient bien comprise. 

■ Les membres votent en toute confidentialite et classent les idees par ordre de priorite, en utilisant generalement 
une notation de 1 a 5,1 etant la note la plus basse et 5 la plus haute. II peut y avoir de nombreux tours de 
vote afin de limiter les idees et de se concentrer sur un plus petit nombre. Apres chaque tour, les voix sont 
decomptees et les idees ayant obtenu le plus de voix sont selectionnees. 

♦ Observation et discussion. Les observations et les discussions fournissent un moyen direct de voir evoluer les 
personnes dans leur environnement mais aussi de savoir comment elles accomplissent leur travail et leurs taches 
et comment elles executent les processus. Elies sont particulierement utiles dans le cas de processus detailles, 
lorsque les personnes qui utilisent le produit ont des difficulty a presenter leurs exigences ou hesitent a le faire. 
L'observation est egalement connue sous I'appellation d'« observation au poste de travail»(job shadowing). 
Elle est habituellement pratiquee en externe par une personne qui observe un expert de I'organisation en train 
d’effectuer un travail. Elle peut egalement etre faite par un «observateur participant»qui conduit lui-meme un 
processus, ou suit une procedure, de fagon a en voir le deroulement et a decouvrir des exigences cachees. 

♦ Facilitation. Elle est decrite a la section 4.1.2.3. La facilitation est utilisee lors de seances ciblees qui rassemblent 
les parties prenantes cles afin de definir les exigences du produit. Des ateliers peuvent etre organises afin de 
definir rapidement les exigences transversales et de reconcilier les differences entre les parties prenantes. Bien 
conduites, de telles seances peuvent, en raison de leur nature interactive au sein du groupe, creer la confiance, 
stimuler les relations et ameliorer la communication entre les participants, ce qui peut conduire a un consensus 
plus solide entre les parties prenantes. De plus, des points a traiter peuvent etre identifies plus tot et etre resolus 
plus rapidement que dans le cadre de seances individuelles. 

Les competences de facilitation sont utilisees notamment dans les situations suivantes : 

■ Joint application design/development (JAD). Des seances de JAD sont organisees dans I’industrie du 
developpement de logiciel. La conduite de ces seances dirigees a pour but essentiel de reunir les experts 
du domaine et I’equipe de developpement, afin de recueillir les exigences et d’ameliorer le processus de 
developpement logiciel. 

■ Quality function deployment (QFD). Dans I’industrie de la fabrication, le QFD est un autre exemple d’une 
technique de facilitation permettant de determiner les caracteristiques essentielles pour le developpement 
de nouveaux produits. La premiere etape du QFD est le recueil des besoins du client, connu sous le nom de 
Voice of the customer. Ces besoins sont ensuite tries et classes de fagon objective par ordre de priorite, et des 
objectifs sont alors determines pour les satisfaire. 

■ Scenarii d’utilisateurs (User Stories). Des scenarii d’utilisateurs, qui sont de courtes descriptions textuelles 
de fonctionnalites requises, sont souvent elabores au cours d’ateliers consacres aux exigences. Les scenarii 
d'utilisateurs decrivent la partie prenante qui beneficie de la caracteristique (role), ce que la partie prenante 
doit realiser (objectif) et le benefice que la partie prenante pourra en tirer (motivation). 
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5.2.2.7 SCHEMAS CONTEXTUELS 

Le schema contextuel est un exemple de modele de perimetre et de contenu. Les schemas contextuels off rent une 
representation visuelle du contenu du produit, en montrant un systeme d’organisation (processus, materiel, systeme 
informatique, etc.) et la maniere dont les personnes et les autres systemes (acteurs, intervenants) interagissent avec 
celui-ci (voir la figure 5-6). Les schemas contextuels montrent les donnees d’entree dans le systeme d’organisation, les 
acteurs ou les intervenants qui fournissent les donnees d’entree, les donnees de sortie du systeme d'organisation et les 
acteurs ou les intervenants recevant les donnees de sortie. 



Figure 5-6. Schema contextuel 
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5.2.2.8 PROTOTYPES 


Le prototypage est une methode permettant un retour d’information rapide par rapport aux exigences, en mettant 
a disposition un modele du produit souhaite avant de le produire effectivement. II s'agit, par exemple, des produits 
a plus petite echelle, des modeles informatiques en 2D et en 3D, des maquettes ou des simulations. Les prototypes 
permettent aux parties prenantes de tester un modele du produit final au lieu de se limiter a discuter de leurs exigences 
de maniere abstraite. Les prototypes soutiennent le concept d’elaboration progressive dans des cycles de vie iteratifs de 
creation de maquettes, d’experimentation par les utilisateurs, de generation de retour d'information et de modifications 
de prototype. Une fois les cycles de retroaction necessaires effectues, les exigences etablies a partir du prototype sont 
suffisamment completes pour permettre de passer a la phase de conception ou de fabrication. 

Le storyboarding est une technique de realisation de prototype qui montre une sequence ou un deroulement par 
le biais d’une serie d'images ou d’illustrations. Les storyboards sont utilises pour des projets de differentes natures 
dans diverses industries, telles que le cinema, la publicity, la conception d’enseignements, et pour des projets de 
developpement agiles ou autres. Dans le domaine du developpement logiciel, les storyboards font appel a des maquettes 
pour illustrer les chemins de navigation a travers les pages Internet, les ecrans, ou d’autres interfaces utilisateur. 


5.2.3 RECUEILUR LES EXIGENCES : DONNEES DE SORTIE 

5.2.3.1 DOCUMENTATION DES EXIGENCES 

La documentation des exigences decrit lafagon dont chacune des exigences satisfait les besoins business du projet. 
Les exigences peuvent etre d’abord d’un niveau general, puis devenir de plus en plus detaillees a mesure que de 
nouvelles informations a leur sujet sont connues. Avant d’etre incorporees a la reference de base, les exigences ne 
doivent pas etre ambigues, mais claires (mesurables et testables), tragables, completes, coherentes et acceptables 
par les parties prenantes cles. Le format d’une documentation des exigences peut aller d’une simple liste de toutes les 
exigences classees par partie prenante et par priorite, a un format plus elabore, comportant un resume, des descriptions 
detaillees et des annexes. 
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Un bon nombre d’organisations classent les exigences en differents types, notamment les exigences business 
et les exigences techniques. Les premieres faisant reference aux besoins des parties prenantes et les autres a la 
fagon dont ces besoins seront mis en oeuvre. Les exigences peuvent etre regroupees par categories permettant de 
parfaire le niveau de detail au fur et a mesure que les exigences sont elaborees. Ces classifications comprennent les 
elements suivants: 

♦ Exigences business. Les exigences business decrivent les besoins generaux de I’organisation, tels que des 
points a traiter ou des opportunity d'affaires, et les raisons pour lesquelles un projet a ete entrepris. 

♦ Exigences des parties prenantes. Les exigences des parties prenantes decrivent les besoins d’une partie 
prenante ou d’un groupe de parties prenantes. 

♦ Exigences de la solution. Les exigences de la solution decrivent les propriety, les fonctions et les caracteristiques 
du produit, du service ou du resultat qui satisferont aux exigences business et a celles des parties prenantes. Les 
exigences de la solution sont, par ailleurs, regroupees en sous-exigences d’ordre fonctionnel et non fonctionnel: 

■ Exigences fonctionnelles. Les exigences fonctionnelles decrivent les comportements du produit. A titre 
d’exemple, on peut citer les processus, les donnees et les interactions que le produit devrait executer. 

■ Exigences non fonctionnelles. Les exigences non fonctionnelles completed les exigences fonctionnelles et 
decrivent les conditions environnementales ou les quality requises pour que le produit soit efficace. A titre 
d’exemple, on peut citer la fiabilite, la surete, la performance, la securite, le niveau de service, la facilite 
d’entretien et la retention ou I’elimination. 

♦ Exigences de transition et de preparation. Les exigences de transition et de preparation decrivent des capacity 
provisoires, telles que la conversion des donnees et les exigences de formation, necessaires pour passer de I’etat 
«tel quel» actuel a I’etat«souhaite»futur. 

♦ Exigences du projet. Les exigences de projet decrivent des actions, des processus ou d’autres conditions 
auxquelles le projet doit satisfaire. Atitre d’exemple, on peut citer les dates des jalons, les obligations contractuelles 
et les contraintes. 

♦ Exigences de qualite. Les exigences de qualite rassemblent toute condition et tout critere necessaire a la 
validation de I'achevement reussi d’un livrable du projet ou au respect d’autres exigences du projet. A titre 
d’exemples, on peut citer les tests, les certifications et les validations. 

5.2.3.2 MATRICE DE TRAQABILITE DES EXIGENCES 

La matrice de tragabilite des exigences est un tableau qui associe les exigences du produit depuis leur origine 
jusqu’aux livrables correspondents. La mise en oeuvre de la matrice de tragabilite des exigences permet d’assurer que 
chaque exigence apporte une valeur business, en la reliant aux objectifs business de I'organisation et aux objectifs du 
projet. Elle procure un moyen de suivre les exigences tout au long du cycle de vie du projet, permettant d’assurer que 
les exigences approuvees dans la documentation sont satisfaites a la fin du projet. Enfin, elle fournit une structure de 
gestion des changements apportes au contenu du produit. 
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Les exigences de tragabilite incluent, notamment: 

♦ les besoins, les opportunity, les buts et les objectifs business ; 

♦ les objectifs du projet; 

♦ les livrables du WBS et le perimetre du projet; 

♦ la conception des produits; 

♦ le developpement des produits ; 

♦ la strategie et les scenarii de test; 

♦ les exigences de niveau general par rapport aux exigences plus detaillees. 

Les attributs associes a chacune des exigences peuvent etre enregistres dans la matrice de tragabilite des 
exigences. Ces attributs aident a definir les informations cles relatives aux exigences. Les attributs habituellement 
utilises dans la matrice de tragabilite des exigences peuvent comprendre un identifiant unique, une description 
textuelle de I’exigence, la raison de son inclusion, le proprietaire, la source, la priority, la version, I’etat actuel 
(par exemple, active, annulee, differee, ajoutee, approuvee, attribuee et terminee) et la date de I'etat. Les attributs 
supplementaires assurant que I’exigence a satisfait les parties prenantes peuvent comprendre la stability, la 
complexity et les criteres d’acceptation. La figure 5-7 donne un exemple de matrice de tragabilite des exigences 
avec les attributs qui lui sont associes. 




Matrice de tragabilite des exigences 




Nom du projet: 


Centre de cout: 


Description du projet: 


Reference 

Reference 

associee 

Description des exigences 

Besoins, 

opportunites, finalites 
et objectifs business 

Objectifs 
du projet 

Livrables 
du WBS 

Conception 
des produits 

Developpe¬ 

ment 

des produits 

Cas 

d’essais 


1.0 








001 

1.1 








1.2 









1.2.1 









2.0 








002 

2.1 









2.1.1 









3.0 








003 

3.1 









3.2 








004 

4.0 








005 

5.0 









Figure 5-7. Exemple de matrice de tragabilite des exigences 
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5.3 DEFINIR LE PERIMETRE 


Definir le perimetre est le processus qui consiste a elaborer une description detaillee du projet et du produit. L’interet 
principal de ce processus est qu’il decrit les limites du produit, du service ou du resultat et les criteres d’acceptation. 
Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la 
figure 5-8. La figure 5-9 represente le diagramme de flux de donnees de ce processus. 


Definir le perimetre 



r i 

Donnees d’entree 


r i 

Outils et techniques 


r i 

Donnees de sortie 



.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion du perimetre 
.3 Documents du projet 

• Journal des hypotheses 

• Documentation 
des exigences 

• Registre des risques 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 


.1 Jugement a dire d'expert 
.2 Analyse des donnees 
•Analyse des alternatives 
.3 Prise de decision 

• Analyse decisionnelle 
multicritere 

.4 Competences 

interpersonnelles et d'equipe 

• Facilitation 

.5 Analyse du produit 


.1 Enonce du perimetre du projet 
.2 Mises a jour des documents 

du projet 

• Journal des hypotheses 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

• Registre des parties 
prenantes 

v J 



v_/ 


Figure 5-8. Definir le perimetre : donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 5-9. Definir le perimetre : diagramme de flux de donnees 


Comme il est possible que les exigences identifies dans le processus Recueillir les exigences ne soient pas toutes 
retenues pour le projet, le processus Definir le perimetre selectionne les exigences finales du projet a partir de la 
documentation des exigences obtenue dans le cadre du processus Recueillir les exigences. II elabore ensuite une 
description detaillee du projet et du produit, du service ou du resultat. 

La preparation d’un enonce detaille du perimetre du projet est elaboree a partir des livrables principaux, des 
hypotheses et des contraintes qui sont documents lors de I’initialisation du projet. Dans la phase de planification du 
projet, la precision de la definition et de la description du perimetre du projet augmente au fur et a mesure que les 
informations sur le projet sont collectees. Les risques, les hypotheses et les contraintes existants sont analyses pour 
s’assurer de leur completude. Le cas echeant, ils sont ajoutes ou mis a jour. Le processus Definir le perimetre peut etre 
tres iteratif. Dans le cas d’un projet a cycle de vie iteratif, une vision generate sera elaboree pour la globalite du projet, 
tandis que le perimetre detaille sera determine par iteration et que la planification detaillee de I'iteration suivante sera 
effectuee pendant que le travail progressera au niveau des livrables et du perimetre du projet en cours. 
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5.3.1 DEFINIR LE PERIMETRE : DONNEES D’ENTREE 


5.3.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet donne une description generate du projet, des caracteristiques 
du produit et des exigences d’approbation. 

5.3.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le plan 
de gestion du perimetre decrit a la section 5.1.3.1, qui documente la maniere dont le perimetre du projet sera defini, 
valide et maitrise. 

5.3.1.3 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses identifie les hypotheses et 
les contraintes relatives au produit, au projet, a I'environnement, aux parties prenantes et aux autres facteurs qui 
peuvent avoir une influence sur le perimetre du projet et le contenu du produit. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences identifie 
les exigences qui seront integrees au perimetre. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques contient les strategies de reponse 
susceptibles d’affecter le perimetre du projet, comme la reduction ou la modification du perimetre du projet ou 
du contenu du produit en vue d’eviter ou d’attenuer un risque. 

5.3.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Definir le 
perimetre, on peut citer: 

♦ la culture de I’organisation ; 

♦ I’infrastructure; 

♦ I’administration du personnel; 

♦ les conditions du marche. 

5.3.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Definir le perimetre, on peut citer: 

♦ les politiques, les procedures et les modeles pour un enonce du perimetre du projet; 

♦ les fichiers de projets anterieurs ; 

♦ les retours d’experience de phases ou de projets anterieurs. 
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5.3.2 DEFINIR LE PERIMETRE : OUTILS ET TECHNIQUES 


5.3.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance ou une experience concernant des projets similaires. 

5.3.2.2 ANALYSE DES DONNEES 

Parmi les exemples de techniques d’analyse des donnees pouvant etre utilisees dans le cadre de ce processus 
figure notamment I'analyse des alternatives. Cette technique peut etre utilisee pour evaluer la mesure dans laquelle les 
exigences et les objectifs identifies dans la charte peuvent etre atteints. 

5.3.2.3 PRISE DE DECISION 

Elle est decrite a la section 5.1.2.2. Parmi les techniques de prise de decision pouvant etre utilisees dans le cadre 
de ce processus figure notamment I'analyse decisionnelle multicritere. Cette technique, decrite a la section 8.1.2.4, fait 
appel a une matrice de decision visant a fournir une approche analytique systematique, afin d'etablir des criteres, tels 
que les exigences, I’echeancier, le budget et les ressources, pour affiner le perimetre du projet et le contenu du produit 
pour le projet. 

5.3.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Elies sont decrites a la section 4.1.2.3. La facilitation constitue un exemple de technique de competences 
interpersonnelles et d’equipe. Utilisee lors d’ateliers et de seances de travail organises avec les parties prenantes 
cles presentant une variete d’attentes et de domaines d’expertise, la facilitation permet de parvenir a une entente 
interfonctionnelle et commune des livrables du projet et des limites du projet et du produit. 

5.3.2.5 ANALYSE DU PRODUIT 

L’analyse du produit permet de definir les produits et les services. Elle comprend des questions qu’il convient de 
poser sur un produit ou un service et la formulation de reponses visant a decrire I’utilisation, les caracteristiques et les 
autres aspects importants des livrables. 

Pour chaque champ d’application, il existe une ou plusieurs methodes habituellement acceptees pour traduire en 
livrables significatifs les descriptions generates du produit ou du service. Les exigences sont prises en compte de 
fagon generate, puis decomposers au niveau de detail requis afin de concevoir le produit fini. Parmi les exemples de 
techniques d’analyse du produit, on peut citer: 

♦ I’organigramme des produits ; 

♦ I’analyse des exigences ; 

♦ I’analyse des systemes ; 

♦ I'ingenierie systeme; 

♦ I’analyse de la valeur; 

♦ I'ingenierie de la valeur. 
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5.3.3 DEFINIR LE PERIMETRE : DONNEES DE SORTIE 


5.3.3.1 ENONCE DU PERIMETRE DU PROJET 

L’enonce du perimetre du projet est la description du perimetre, des principaux livrables, des hypotheses et des 
contraintes du projet. L'enonce du perimetre du projet en documente la totalite, y compris le perimetre du projet et 
le contenu du produit. II decrit en detail les livrables du projet. II permet egalement une comprehension commune du 
perimetre du projet par les parties prenantes. II peut contenir des exclusions explicites qui aident a gerer les attentes 
des parties prenantes. II permet a I’equipe projet d’effectuer une planification plus detaillee, guide son travail lors de 
I’execution et fournit une reference de base pour evaluer si les demandes de changement ou de travaux supplementaires 
sont comprises ou non dans le perimetre du projet. 

Le degre et le niveau de detail utilises dans l'enonce du perimetre du projet pour definir le travail a effectuer et le 
travail a exclure peuvent contribuer a determiner la capacite de maTtrise du perimetre global du projet par I’equipe de 
management de projet. L’enonce detaille du perimetre du projet comprend les elements suivants, soit directement, soit 
par reference a d’autres documents : 

♦ Description du contenu du produit. Elle elabore progressivement les caracteristiques du produit, du service ou 
du resultat decrit dans la charte du projet et la documentation des exigences. 

♦ Livrables. Tout type de produit, de resultat ou de capacite a realiser un service, de caractere unique et verifiable, 
qui est produit pour achever un processus, une phase ou un projet. Les livrables comprennent egalement des 
resultats auxiliaires, tels que des rapports et la documentation de management du projet. La description de ces 
livrables peut etre presentee de fagon resumee ou tres detaillee. 

♦ Criteres d’acceptation. Un ensemble de conditions a remplir pour que les livrables soient acceptes. 

♦ Exclusions du projet. Elies identifient de ce qui est exclu du projet. L'enonce explicite de ce qui ne fait pas partie 
du perimetre du projet aide a gerer les attentes des parties prenantes et peut limiter la derive du perimetre. 

Bien que la charte du projet et l'enonce du perimetre du projet soient parfois pergus comme presentant un certain 
degre de redondance, ils different par leur niveau de detail. La charte du projet contient des informations generates, 
tandis que l’enonce du perimetre du projet contient une description detaillee des composants du perimetre. Ces 
composants sont progressivement elabores tout au long du projet. Le tableau 5-1 decrit certains des elements cles 
de chacun de ces documents. 
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Tableau 5-1. Elements de la charte du projet et de I’enonce du perimetre du projet 


Charte du projet 

Objet du projet 

Objectifs mesurables du projet et criteres 
de reussite correspondants 

Exigences de haut niveau 

Description du projet, limites et principaux 
livrables 

Risque global du projet 

Echeancier a jalons recapitulate 

Ressources financieres preapprouvees 

Liste des principales parties prenantes 

Exigences d’acceptation du projet 
(c’est-a-dire, ce qui definit la reussite du 
projet, la personne qui decide que le projet 
est reussi et celle qui valide le projet) 

Criteres de sortie du projet (c’est-a-dire les 
conditions a respecter afin de clore ou 
d’annuler le projet ou la phase) 

Chef de projet designe, sa responsabilite 
et son niveau d’autorite 

Nom et niveau d’autorite du sponsor ou 
des autres personnes qui autorisent 
la charte du projet 


Enonce du perimetre du projet 

Description du perimetre du projet 
(elabore progressivement) 

Livrables du projet 

Criteres d’acceptation 

Exclusions du projet 


5.3.3.2 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses est mis a jour a I'aide 
d’hypotheses ou de contraintes supplementaires identifies lors de ce processus. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut etre 
mise a jour a I’aide des exigences supplementaires ou modifies. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des 
exigences peut etre actualisee afin de refleter les mises a jour de la documentation des exigences. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Lorsque d’autres informations sur les parties 
prenantes existantes ou nouvelles sont reunies a Tissue de ce processus, elles sont consignees dans le registre 
des parties prenantes. 
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5.4 CREER LE WBS 


Creer I’organigramme des travaux du projet (WBS) est le processus qui consiste a subdiviser les livrables et le travail 
du projet en composants plus petits et plus faciles a maTtriser. L’interet principal de ce processus est qu’il fournit un 
cadre de ce qui doit etre livre. Ce processus est execute au moins une fois ou a plusieurs moments predefinis durant le 
projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la 
figure 5-10. La figure 5-11 represente le diagramme de flux de donnees de ce processus. 


Creer le WBS 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion du perimetre 
.2 Documents du projet 

• Enonce du perimetre 
du projet 

• Documentation 
des exigences 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

v---' 


Outils et techniques 


.1 Jugement a dire d'expert 
.2 Decomposition 

V___/ 


Donnees de sortie 


.1 Reference de base 
du perimetre 

.2 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Documentation 
des exigences 

V___/ 


Figure 5-10. Creer le WBS: donnees d’entree, outils, techniques et donnees de sortie 


Plan 

de management 
du projet 


Plan de management du projet 
• Plan de gestion du perimetre 


Documents 
du projet 


Documents du projet 

• Enonce du perimetre du projet 

• Documentation des exigences 


Entreprise/ 

Organisation 



• Reference de base 
du perimetre 


Plan 

de management 
du projet 


Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Documentation des exigences 


Documents 
du projet 


• Facteurs environnementaux de I’organisation 

• Actifs organisationnels 


Figure 5-11. Creer le WBS: diagramme de flux de donnees 
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Le WBS est une decomposition hierarchique du perimetre total du projet, qui definit le travail que I'equipe projet doit 
realiser pour atteindre les objectifs du projet et produire les livrables requis. Le WBS organise et definit le perimetre total 
du projet et represente le travail specifie dans I’enonce du perimetre du projet actuellement approuve. 

Le travail prevu se trouve au niveau le plus bas des composants du WBS, qui sont appeles lots de travaux. Un lot de 
travaux peut etre utilise pour grouper les activites grace auxquelles le travail est planifie, maTtrise, et son cout estime. 
Dans le contexte du WBS, le travail correspond aux produits ou aux livrables du travail resultant de I’activite, et non pas 
a I'activite elle-meme. 


5.4.1 CREER LE WBS : DONNEES D’ENTREE 

5.4.1.1 PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet figure, entre autres, le plan de gestion du perimetre. Decrit 
a la section 5.1.3.1, le plan de gestion du perimetre documente la maniere dont le WBS sera cree a partir de I'enonce 
du perimetre du projet. 

5.4.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Enonce du perimetre du projet. II est decrit a la section 5.3.3.1. L'enonce du perimetre du projet decrit le travail 
qui sera mis en oeuvre et le travail qui sera exclu. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. Des exigences detaillees decrivent la fagon 
dont chacune des exigences satisfait aux besoins du projet. 

5.4.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Creer le 
WBS figurent notamment les standards de WBS specifiques a chaque secteur d’activite en adequation avec la nature du 
projet. Ces standards sectoriels peuvent servir de sources de reference externes pour la creation du WBS. 

5.4.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Creer le WBS, on peut citer: 

♦ les politiques, les procedures et les modeles concernant le WBS ; 

♦ les fichiers des projets anterieurs; 

♦ les retours d’experience des projets anterieurs. 
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5.4.2 CREER LE WBS : OUTILS ET TECHNIQUES 


5.4.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance ou une experience concemant des projets similaires. 

5.4.2.2 DECOMPOSITION 

La decomposition est une technique utilisee pour diviser et subdiviser le perimetre du projet et les livrables du projet 
en elements plus petits et plus faciles a gerer. Le lot de travaux est le travail defini au plus bas niveau du WBS, pour lequel 
le cout et la duree peuvent etre estimes et geres. Le niveau de decomposition est souvent dicte par le degre de controle 
necessaire a une gestion efficace du projet. Le niveau de detail des lots de travaux depend de la taille et de la complexite 
du projet. La decomposition du travail total du projet en lots de travaux met generalement en jeu les activites suivantes : 

♦ I’identification et I’analyse des livrables et du travail associe; 

♦ la structuration et I’organisation du WBS ; 

♦ la decomposition des niveaux superieurs du WBS en composants detailles de niveaux inferieurs ; 

♦ I’etablissement de codes d’identification et leur attribution aux composants du WBS ; 

♦ la verification que le degre de decomposition des livrables est approprie. 

La figure 5-12 illustre une partie du WBS comportant quelques branches decomposees jusqu’au niveau des lots 
de travaux. 



L’organigramme des travaux du projet (work breakdown structure, WBS) est donne a titre indicatif uniquement. 
II ne vise pas a representer tout le perimetre d'un projet specifique ni a laisser entendre 
que c’est le seul moyen d’organiser un WBS pour ce type de projet 


Figure 5-12. Exemple de WBS decompose jusqu’au niveau des lots de travaux 
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Une structure de WBS peut etre creee en utilisant differentes approches. Certaines des methodes les plus repandues 
font appel, entre autres, a I’approche descendante (top-down), a I’utilisation de directives specifiques a I'organisation et 
a I’utilisation de modeles de WBS. Une approche ascendante (bottom-up) peut etre utilisee pour des sous-composants. 
La structure du WBS peut etre representee de diverses manieres, par exemple : 

♦ en utilisant les phases du cycle de vie du projet comme deuxieme niveau de decomposition, les livrables du 
produit et du projet etant inseres au troisieme niveau, comme illustre sur la figure 5-13 ; 

♦ en utilisant les livrables principaux comme deuxieme niveau de decomposition, comme illustre sur la figure 5-14; 

♦ en integrant des sous-composants qui peuvent etre executes par des organisations externes a I'equipe projet, 
tels qu’un travail sous-traite. Dans le cadre d’un tel contrat de sous-traitance, le fournisseur developpe alors le 
WBS correspondant a la partie de travail sous contrat. 



L’organigramme des travaux du projet (work breakdown structure, WBS) est donne a titre indicatif uniquement. 

II ne vise pas a representer tout le perimetre d'un projet specifique ni a laisser entendre que c’est le seul moyen d’organiser 

un WBS pour ce type de projet 


Figure 5-13. Exemple de WBS organise par phases 
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L’organigramme des travaux du projet (work breakdown structure, WBS) est donne a titre indicatif uniquement. 

II ne vise pas a representer tout le perimetre d'un projet specifique ni a laisser entendre que c'est le seul moyen d’organiser 

un WBS pour ce type de projet. 


Figure 5-14. Exemple de WBS avec les principaux livrables 


La decomposition des composants des niveaux superieurs du WBS necessite une subdivision du travail de chaque 
livrable, ou sous-composant, en ses composants les plus fondamentaux, de fagon a ce que les composants du WBS 
represented des produits, des services ou des resultats verifiables. En cas d’utilisation d’une approche agile, les recits 
peuvent etre decomposes en scenarios d’utilisateurs. Le WBS peut etre presente de plusieurs fagons, notamment a 
I’aide d’un simple graphique, d’un organigramme ou de toute autre methode qui permet d’identifier un organigramme 
hierarchique. Afin de verifier I’exactitude de la decomposition, il est necessaire de s'assurer que les composants des 
niveaux inferieurs du WBS sont les composants a la fois necessaires et suffisants pour achever les livrables de plus 
haut niveau correspondants. Des livrables differents peuvent avoir des niveaux de decomposition differents. Pour arriver 
au lot de travaux, le travail de certains livrables pourra etre simplement decompose au niveau inferieur alors que, pour 
d’autres, une decomposition a plusieurs niveaux sera necessaire. Plus le travail est decompose en niveaux plus detailles, 
plus la capacite de planifier, de gerer et de maTtriser le travail est grande. Toutefois, une decomposition excessive peut 
conduire a un travail de gestion improductif, a une mauvaise utilisation des ressources, a une efficacite reduite dans 
I'execution du travail et a des difficulty dans le cumul des donnees sur differents niveaux du WBS. 

La decomposition d’un livrable ou d’un sous-composant dont I'achevement se situe dans un avenir eloigne n’est 
parfois pas possible. L’equipe de management de projet attend habituellement que le livrable ou le sous-composant soit 
convenu avant de developper les details du WBS. Cette technique est parfois appelee planification en vagues (rolling 
wave planning). 
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Le WBS represente le travail complet du produit et du projet, y compris le travail de management de projet. Le cumul 
du travail des niveaux inferieurs doit etre equivalent au travail implique par les niveaux superieurs, de fagon a ce que 
rien ne soit oublie et qu’aucun travail inutile ne soit effectue. Ceci est parfois appele la regie du 100 %. 

Pour obtenir de plus amples informations sur le WBS, veuillez consulter la publication intitulee Practice Standard 
for Work Breakdown Structures - Second Edition [15] (en anglais seulement). Ce standard presente des exemples de 
modeles de WBS specifiques a differentes industries, qui peuvent etre adaptes a des projets distincts dans un champ 
d’application particular. 


5.4.3 CREER LE WBS : DONNEES DE SORTIE 

5.4.3.1 REFERENCE DE BASE DU PERIMETRE 

La reference de base du perimetre est la version approuvee d’un enonce du perimetre, du WBS et du dictionnaire du 
WBS associe. Elle ne peut etre modifiee qu'a I'aide de procedures formelles de maTtrise des changements. En outre, elle 
est utilisee comme base de comparaison. C'est un composant du plan de management du projet. Les composants de la 
reference de base du perimetre sont notamment les suivants : 

♦ Enonce du perimetre du projet. L’enonce du perimetre du projet comprend la description du perimetre du 
projet, des principaux livrables, des hypotheses et des contraintes (voir la section 5.3.3.1). 

♦ WBS. Le WBS est une decomposition hierarchique du perimetre total du projet, qui definit le travail que I’equipe 
projet doit realiser pour atteindre les objectifs du projet et produire les livrables requis. Chaque niveau inferieur 
du WBS represente un niveau de detail accru de la definition du travail du projet. 

♦ Lot de travaux. Le lot de travaux est le niveau le plus bas du WBS. II est assorti d’un identifiant unique. Ces 
identifiants fournissent une structure pour le regroupement hierarchique des couts, de I’echeancier et des 
informations sur les ressources ainsi qu’une forme de code WBS. Chaque lot de travaux represente une partie 
d’un centre de consolidation. Un centre de consolidation est un point de maTtrise du management ou le perimetre, 
le budget et I’echeancier sont integres et compares a la valeur acquise pour la mesure de performance. II se 
compose d’au moins deux lots de travaux dont chacun est associe a un seul centre de consolidation. 

♦ Lot de planification. Un centre de consolidation peut comprendre un ou plusieurs lots de planification (planning 
package). Un lot de planification est un element de I'organigramme des travaux du projet a un niveau inferieur 
a celui du centre de consolidation et a un niveau superieur a celui du lot de travaux, dont le perimetre du travail 
est connu mais sans le detail des activites de I’echeancier. 
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♦ Dictionnaire du WBS. Le dictionnaire du WBS est un document qui fournit des informations detaillees sur 
le livrable, sur I'activite et sur I’echeancier pour chaque composant du WBS. Le dictionnaire du WBS est un 
document de support du WBS. La plupart des informations incluses dans le dictionnaire du WBS sont creees par 
d’autres processus et ajoutees a ce document ulterieurement. Les informations contenues dans le dictionnaire 
du WBS peuvent comprendre, entre autres: 

■ I'identifiant du code WBS ; 

■ la description du travail; 

■ les hypotheses et les contraintes ; 

■ I'organisation responsable; 

■ les jalons de I’echeancier; 

■ les activites associees de I’echeancier; 

■ les ressources necessaires; 

■ les estimations de couts ; 

■ les exigences de qualite; 

■ les criteres d’ acceptation ; 

■ les references techniques ; 

■ les informations concernant I'accord. 

5.4.3.2 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

■ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses est mis a jour a I’aide 
d’hypotheses ou de contraintes supplementaires identifies lors du processus Creer le WBS. 

■ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut 
etre mise a jour afin d'inclure les changements approuves issus du processus Creer le WBS. 
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5.5 VALIDER LE PERIMETRE 


Valider le perimetre est le processus qui consiste a formaliser I’acceptation des livrables termines du projet. L’interet 
principal de ce processus est qu’il confere un caractere objectif a I’acceptation et accroTt les chances d’acceptation 
du produit, du service ou du resultat final en validant chacun des livrables. Ce processus est execute periodiquement 
pendant toute laduree du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus 
sont represents sur la figure 5-15. La figure 5-16 represente le diagramme de flux de donnees de ce processus. 


Valider le perimetre 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion 
des exigences 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Rapport de qualite 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

.3 Livrables acceptes 

.4 Donnees de performance 

d'execution 

v_y 


Outils et techniques 


.1 Inspection 


.2 Prise de decision 


• Vote 


V 

_ 


Donnees de sortie 


.1 Livrables acceptes 
.2 Information sur 

la performance d'execution 
.3 Demandes de changement 
.4 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

---y 


Figure 5-15. Valider le perimetre: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion des exigences 

• Reference de base du perimetre 


4.3 

Dinger et gerer 
I’execution 
du projet 

Donnees de performance 
d’execution 


•••• 


8.3 

MaTtriser 
la qualite 

Livrables verifies 


Documents 
du projet 


Documents du projet 

• Registre des retours d’experience 

• Rapport de qualite 

• Documentation des exigences 

• Matrice de tragabilite des exigences 



Documentation des exigences 
Matrice de tragabilite 
des exigences 


Figure 5-16. Valider le perimetre: diagramme de flux de donnees 


Les livrables verifies, issus du processus MaTtriser la qualite, sont passes en revue avec le client ou le sponsor, afin de 
s’assurer qu’ils ont ete accomplis de maniere satisfaisante et que I’acceptation formelle de ces livrables a ete obtenue 
de la part du client ou du sponsor. Dans le cadre de ce processus, les donnees de sortie issues de la planification dans 
la gestion du perimetre du projet, constituent la base de la mise en oeuvre de la validation et de I'acceptation finale. Ces 
donnees de sorties peuvent inclure la documentation des exigences ou la base de reference du perimetre, ainsi que 
les donnees de performance d’execution issues des processus d’execution dans d’autres domaines de connaissance. 

Le processus Valider le perimetre differe du processus MaTtriser la qualite en ce que la validation du perimetre 
concerne principalement I’acceptation des livrables, tandis que la maTtrise de la qualite vise principalement a s’assurer 
que les livrables sont corrects et qu'ils satisfont aux exigences de qualite specifies. Le processus MaTtriser la qualite 
est generalement effectue avant le processus Valider le perimetre, bien que ces deux processus puissent etre executes 
en parallele. 


164 


Premiere partie - Guide 


































































5.5.1 VALIDER LE PERIMETRE : DONNEES D’ENTREE 


5.5.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de management du projet specifie 
comment I'acceptation formelle des livrables acheves du projet sera obtenue. 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences decrit la fagon 
dont les exigences du projet sont validees. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre est 
comparee aux resultats reels de fagon a determiner si un changement ou une action corrective ou preventive 
s'avererait necessaire. 

5.5.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4. 3.1. Les retours d’experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer I'efficacite de la validation des livrables. 

♦ Rapports de qualite. Ms sont decrits a la section 8.2.3.1. Les informations presentees dans le rapport de qualite 
peuvent inclure toutes les questions d’assurance qualite traites ou transmis par I’equipe, les recommandations 
d’amelioration et le recapitulate des resultats du processus MaTtriser la qualite. Ces informations sont passees 
en revue avant I’acceptation du produit. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. Les exigences sont comparees aux resultats 
reels de fagon a determiner si un changement ou une action corrective ou preventive s'avererait necessaire. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
contient des informations sur les exigences, notamment leur validation. 

5.5.1.3 LIVRABLES VERIFIES 

Les livrables verifies sont des livrables de projet qui ont ete acheves et verifies pour en assurer I’exactitude, par le 
processus MaTtriser la qualite. 

5.5.1.4 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution comportent le degre de conformite aux 
exigences, le nombre de non-conformites, la gravite des non-conformites ou le nombre des cycles de validation effectues 
au coursd’une periode. 
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5.5.2 VALIDER LE PERIMETRE : OUTILS ET TECHNIQUES 


5.5.2.1 INSPECTION 

Elle est decrite a la section 8.3.2.3. L'inspection comprend des activites telles que les mesures, les examens et 
les validations qui permettent de determiner si le travail et les livrables sont conformes aux exigences et aux criteres 
d’acceptation du produit. Selon les cas, les inspections sont parfois appelees revues, revues de produit ou revues 
structures. Dans certains champs d'application, ces differents termes ont des sens specifiques et plus restreints. 

5.5.2.2 PRISE DE DECISION 

Elle est decrite a la section 5.2.2.4. Le vote constitue un exemple de prise de decision qui peut etre utilise dans 
le cadre de ce processus. Le vote permet de parvenir a une conclusion lorsque la validation est mise en oeuvre par 
I’equipe projet et d’autres parties prenantes. 


5.5.3 VALIDER LE PERIMETRE : DONNEES DE SORTIE 

5.5.3.1 LIVRABLES ACCEPTES 

Les livrables conformes aux criteres d’acceptation sont formellement acceptes et approuves par le client ou le 
sponsor. Une documentation formelle, obtenue du client ou du sponsor, reconnaissant I’acceptation des livrables du 
projet par les parties prenantes, est transmise au processus Clore le projet ou la phase (voir la section 4.7). 

5.5.3.2 INFORMATIONS SUR LA PERFORMANCE D’EXECUTION 

Les informations sur la performance d’execution incluent les informations relatives a I'avancement du projet, comme 
les livrables qui ont ete acceptes et ceux qui n’ont pas ete acceptes ainsi que les raisons de ces choix. Ces informations 
sont documentees comme decrit a la section 10.3.3.1 et communiquees aux parties prenantes. 

5.5.3.3 DEMANDES DE CHANGEMENT 

Les livrables acheves qui n’ont pas ete formellement acceptes sont documents avec les raisons de la non-acceptation 
desdits livrables. Ces livrables peuvent faire I’objet d’une demande de changement pour correction de defauts. Les 
demandes de changement (decrites a la section 4.3.3.4) sont passees en revue et traitees par le processus Maitriser 
les changements (voir la section 4.6). 
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5.5.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est 
mis a jour a I'aide des informations sur les difficultes rencontrees et les moyens pour les eviter ainsi que sur les 
approches qui ont permis de valider les livrables. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut etre 
mise a jour a I’aide des resultats reels de I’activite de validation. II est particulierement interessant de savoir 
quand les resultats reels sont meilleurs que I'exigence ou lorsqu’une exigence a ete levee. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
est mise a jour a I'aide des resultats de la validation, notamment la methode utilisee et le resultat obtenu. 


5.6 MAITRISER LE PERIMETRE 

MaTtriser le perimetre est le processus qui consiste a surveiller I’etat du perimetre du projet et du contenu du produit 
et a gerer les changements affectant la reference de base du perimetre. L'interet principal de ce processus est qu'il 
permet de conserver la reference de base du perimetre tout au long du projet. Ce processus est execute tout au long du 
projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la 
figure 5-17. La figure 5-18 represente le diagramme de flux de donnees de ce processus. 


Maitriser le perimetre 


Donnees d’entree 


.1 Plan de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion 
des exigences 

• Plan de gestion 
des changements 

• Plan de gestion 

de la configuration 

• Reference de base 
du perimetre 

• Reference de base 
de la performance 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

.3 Donnees de performance 

d'execution 

.4 Actifs organisationnels 
V___^ 


Outils et techniques 


.1 Analyse des donnees 

• Analyse des ecarts 

• Analyse de la tendance 

V___y 


Donnees de sortie 


.1 Information sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 

de management du projet 

• Plan de gestion 
du perimetre 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

• Reference de base 
de la performance 

.4 Mises a jour des documents 

du projet 

• Registre des retours 
d'experience 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

V___y 


Figure 5-17. Maitriser le perimetre : donnees d’entree, outils, techniques et donnees de sortie 
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Plan de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion des exigences 

• Plan de gestion des changements 

• Plan de gestion de la configuration 

• Reference de base du perimetre 

• Reference de base 
de la performance 


Documents 
du projet 


■•••! 


Documents du projet 

• Registre des retours d’experience • 

• Documentation des exigences 2 

• Matrice de tragabilite * 

des exigences • 


4.3 

Diriger et gerer 
le travail 
du projet 


••••! 


Donnees de performance 
d’execution 


Entreprise/ 

Organisation 



Registre des retours 
d’experience 

Documentation des exigences 
Matrice de tragabilite 
des exigences 


• Actifs organisationnels 


Figure 5-18. Maitriser le perimetre: diagramme de flux de donnees 


La martrise du perimetre du projet assure que tous les changements demandes et les actions correctives ou 
preventives recommandees ont ete traites par le processus MaTtriser les changements (voir la section 4.6). La martrise 
du perimetre permet egalement de gerer les changements reels, quand ils se presented, et est integree aux autres 
processus de maitrise. L’expansion non controlee du perimetre du projet ou du contenu du produit sans ajustements de 
la duree, du cout et des ressources est appelee derive du perimetre (scope creep). Les changements sont inevitables 
et, de ce fait, un processus de martrise des changements, quel qu'en soit le type, est obligatoire pour chaque projet. 
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5.6.1 MATTRISER LE PERIMETRE : DONNEES D’ENTREE 


5.6.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre documente la 
maniere dont le contenu du produit et le perimetre du projet seront maTtrises. 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences decrit la fagon 
dont les exigences du projet seront gerees. 

♦ Plan de gestion des changements. II est decrit a la section 4.2.3.1. Le plan de gestion des changements definit 
le processus de gestion des changements du projet. 

♦ Plan de gestion de la configuration. II est decrit a la section 4.2.3.1. Le plan de gestion de la configuration 
definit les elements qui sont configurables, ceux qui necessitent une maTtrise formelle des changements et le 
processus pour maTtriser les changements apportes a ces elements. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre est 
comparee aux resultats reels de fagon a determiner si un changement ou une action corrective ou preventive 
s'avererait necessaire. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Dans le cadre de I’analyse de 
la valeur acquise, la reference de base de la performance est comparee a I’etat reel afin de determiner si un 
changement, une action corrective ou preventive s'avere necessaire. 

5.6.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer la maTtrise du perimetre. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences permet de 
detectertoute deviation au niveau du perimetre ou du contenu respectivement convenu pour le projet ou le produit. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
aide a detecter I’impact sur les objectifs du projet de tout changement ou de tout ecart par rapport a la reference 
de base du perimetre. Elle peut egalement faire etat des exigences a maTtriser. 

5.6.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Les donnees de performance d'execution peuvent inclure le nombre de demandes de changement regues, le nombre 
de demandes acceptees ainsi que le nombre de livrables verifies, valides et acheves. 
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5.6.1.4 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser le perimetre, on peut citer: 

♦ les politiques, les procedures et les instructions existantes, formelles et informelles, relatives au perimetre, au 
contenu et a la maTtrise ; 

♦ les methodes et les modeles de maTtrise et de communication a utiliser. 

5.6.2 MAITRISER LE PERIMETRE : OUTILS ET TECHNIQUES 

5.6.2.1 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees qui peuvent etre utilisees lors du processus MaTtriser le perimetre 
figurent notamment les elements suivants: 

♦ Analyse des ecarts. Elle est decrite a la section 4.5.2.2. L’analyse des ecarts permet de comparer la reference 
de base par rapport aux resultats reels et de determiner si I'ecart ne depasse pas le seuil ou si I’action preventive 
ou corrective est appropriee. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5.2.2. L’analyse de la tendance consiste a examiner les 
performances du projet dans le temps pour determiner si elles s’ameliorent ou si elles se degradent. 

Les aspects importants de la maTtrise du perimetre du projet comprennent la determination de la cause et du degre 
des ecarts par rapport a la reference de base du perimetre (voir la section 5.4.3.1) mais aussi la decision quant a la 
necessity ou non d’appliquer une action corrective ou preventive. 


5.6.3 MAITRISER LE PERIMETRE : DONNEES DE SORTIE 

5.6.3.1 INFORMATIONS SUR LA PERFORMANCE D’EXECUTION 

Les informations sur la performance d’execution comportent des informations correlees et contextuelles sur la 
performance du perimetre du projet et du contenu du produit par rapport a la reference de base du perimetre. Elles 
peuvent inclure les categories des changements regues, les ecarts identifies par rapport au perimetre et leurs causes, 
la maniere dont elles affectent I’echeancier ou le cout et les previsions relatives a la performance future du perimetre. 

5.6.3.2 DEMANDES DE CHANGEMENT 

Elles sont decrites a la section 4.3.3.4. L’analyse de la performance du projet peut conduire a une demande de 
changement des references de base de I’echeancier et du perimetre ou d’autres composants du plan de management 
du projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements 
(voir la section 4.6). 
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5.6.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre peut etre mis 
a jour pour refleter un changement dans la fagon dont le perimetre est gere. 

♦ Reference de base du perimetre. II est decrit a la section 5.4.3.1. Les changements apportes a la reference de 
base du perimetre sont incorpores a la suite de changements approuves du perimetre, de I’enonce du perimetre, 
du WBS ou du dictionnaire du WBS. Lorsque les ecarts de perimetre sont tres importants, une revue de la reference 
de base du perimetre est necessaire, de fagon a disposer d’une base realiste de mesure de performance. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. Les changements apportes a la reference 
de base de I’echeancier sont incorpores a la suite de changements approuves du perimetre, des ressources ou 
des estimations de couts. Lorsque les ecarts de delai sont tres importants, une revue de la reference de base de 
I’echeancier est necessaire, de fagon a disposer d’une base realiste de mesure de performance. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference 
de base des couts sont incorpores a la suite de changements approuves du perimetre, des ressources ou des 
estimations de couts. Lorsque les ecarts de cout sont tres importants, une revision de la reference de base des 
couts est necessaire, de fagon a disposer d’une base realiste de mesure de performance. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Les changements apportes a 
la reference de base de la performance sont incorpores a la suite de changements approuves du perimetre, 
des performances de I’echeancier ou des estimations de couts. Lorsque les ecarts de performance sont tres 
importants, une demande de changement est lancee pour revoir la base de reference de la performance de fagon 
a disposer d’une base realiste de mesure de performance. 

5.6.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d'experience peut 
etre mis a jour a I'aide de techniques efficaces pour maTtriser le perimetre, y compris les causes des ecarts et 
les actions correctives choisies. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut etre 
mise a jour a I’aide des exigences supplementaires ou modifiees. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
peut etre actualisee afin de refleter les mises a jour de la documentation des exigences. 
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GESTION DE L’ECHEANCIER DU PROJET 

La gestion de I’echeancier du projet inclut les processus permettant de gerer I'achevement du projet dans le temps 
voulu. Les processus de gestion de I’echeancier du projet sont les suivants : 

6.1 Planifier la gestion de I’echeancier —Ce processus consiste a etablir les politiques, les procedures et la 
documentation pour la planification, le developpement, la gestion, I’execution et la maTtrise de I'echeancier du projet. 

6.2 Definir les activites —Ce processus consiste a identifier et a documenter les actions specifiques a entreprendre 
pour produire les livrables du projet. 

6.3 Organiser les activites en sequence —Ce processus consiste a identifier et a documenter les relations entre 
les activites du projet. 

6.4 Estimer la duree des activites —Ce processus consiste a estimer le nombre de periodes de travail requises pour 
accomplir chacune des activites avec les ressources estimees. 

6.5 Elaborer I’echeancier —Ce processus consiste a elaborer le modele d’echeancier du projet a partir de (’analyse 
des sequences d'activites, des durees, des besoins en ressources et des contraintes de I’echeancier a des fins 
d’execution et de maTtrise du projet. 

6.6 Maitriser I’echeancier —Ce processus consiste a suivre I’etat du projet, dans le but de mettre a jour I’echeancier 
du projet et de gerer les changements affectant la reference de base de I'echeancier. 

La figure 6-1 donne une vue d’ensemble des processus de gestion de I’echeancier du projet. Les processus de 
gestion de I'echeancier du projet sont presentes comme des processus distincts aux interfaces clairement definies 
tandis que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre 
completement detaillees dans le Guide PMBOK ®. 
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Vue d’ensemble de la gestion 
de l’echeancier du projet 


6.1 Planifier la gestion 
de l’echeancier 


.1 Donnees d'entree 
.1 Charte du projet 
.2 Plan de management du projet 
.3 Facteurs environnementaux 
de ^organisation 
.4 Actifs organisationnels 

.2 Outils et techniques 

.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Reunions 

3 Donnees de sortie 
.1 Plan de gestion 
de I'echeancier 

v_/ 


6.4 Estimer la duree 
des activites 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Estimation paranalogie 
.3 Estimation parametrique 
.4 Estimation a trois points 
.5 Estimation ascendante 
.6 Analyse des donnees 
.7 Prise de decision 
.8 Reunions 

.3 Donnees de sortie 
.1 Estimations de durees 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

V___/ 


6.2 Definir les activites 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Facteurs environnementaux 
de I'organisation 
.3 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Decomposition 
.3 Planification en vagues 
.4 Reunions 

.3 Donnees de sortie 
.1 Liste d activites 
.2 Attributs des activites 
.3 Liste des jalons 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 

V_ J 


6.5 Elaborer l’echeancier 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Accords 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettechniques 
.1 Analyse du diagramme 
de reseau 

.2 Methode du chemin critique 
.3 Optimisation des ressources 
.4 Analyse des donnees 
.5 Avances et retards 
.6 Compression de I'echeancier 
.7 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.8 Planification des releases 
agile 

.3 Donnees de sortie 
.1 Reference de base 
de I'echeancier 
.2 Echeancier du projet 
.3 Donnees de I'echeancier 
.4 Calendriers du projet 
.5 Demandes de changement 
.6 Mises a jour du plan 
de management du projet 
.7 Mises a jour des documents 
du projet 

V___/ 


6.3 Organiser les activites 
en sequence 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
.2 Outils ettechniques 

.1 Methode des antecedents 
.2 Determination et integration 
des dependances 
.3 Avances et retards 
.4 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.3 Donnees de sortie 

.1 Diagrammes de reseau 
du projet 

.2 Mises a jour des documents 
du projet 

V___/ 


6.6 Maitriser 
l’echeancier 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d’execution 

.4 Actifs organisationnels 

.2 Outils ettechniques 
.1 Analyse des donnees 
.2 Methode du chemin critique 
.3 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.4 Optimisation des ressources 
.5 Avances et retards 
.6 Compression de I'echeancier 

.3 Donnees de sortie 
.1 Information sur 

la performance d'execution 
.2 Previsions de I'echeancier 
.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du pro jet 

V___/ 


Figure 6-1. Vue d’ensemble de la gestion de I’echeancier du projet 
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PRINCIPAUX CONCEPTS DE LA GESTION DE L’ECHEANCIER DU PROJET 


La construction de I’echeancier du projet fournit un plan detaille qui indique comment et quand le projet livrera les 
produits, les services et les resultats definis dans le perimetre du projet. Cet outil, qui permet de gerer les attentes des 
parties prenantes, sert de base a la communication des performances. 

L’equipe de management de projet choisit une methode de planification, telle que le chemin critique ou I’approche 
agile. Les donnees specifiques au projet, comme les activites, les dates planifiees, les durees, les ressources, les 
dependences et les contraintes, sont ensuite integrees dans I’outil de planification afin de creer un modele d’echeancier 
pour le projet. Le resultat est un echeancier du projet. La figure 6-2 presente un echeancier montrant comment la 
methode de planification, I’outil de planification et les donnees de sortie des processus de gestion de I'echeancier du 
projet interagissent pour creer un modele d’echeancier. 

Pour les projets de moindre envergure, la definition des activites et leur organisation en sequence, I'estimation de la 
duree des activites et I'elaboration du modele d’echeancier sont si etroitement liees qu'elles sont considerees comme 
un processus unique pouvant etre execute par une seule personne en un temps relativement court. Ces processus 
sont presentes ici comme des elements distincts, car les outils et techniques utilises sont differents pour chacun 
d’eux. Certains de ces processus sont presentes plus en detail dans le Practice Standard for Scheduling (en anglais 
seulement) [2], 

Dans la mesure du possible, I’echeancier du projet detaille doit pouvoir etre adapte tout au long du projet en fonction 
des connaissances acquises, de la meilleure comprehension des risques et des activites a valeur ajoutee. 
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Figure 6-2. Vue d’ensemble d’un echeancier 


176 


Premiere partie - Guide 


















































































































TENDANCES ET PRATIQUES EMERGENTES EN GESTION DE L’ECHEANCIER DU PROJET 


Avec les hauts niveaux d’incertitude et d’imprevisibilite sur un marche mondial dynamique et ultra competitif oil 
il est difficile de definir un perimetre a long terme, il devient de plus en plus important d’etablir un cadre contextuel 
pour adopter et adapter de maniere efficace des pratiques de developpement visant a repondre a revolution des 
besoins de I’environnement. Une planification adaptative definit un plan, mais reconnaft qu’une fois le travail lance, 
les priorites peuvent changer et que le plan doit refleter les nouvelles connaissances. 

Parmi les pratiques emergentes en planification du projet figurent notamment les elements suivants: 

♦ Planification iterative avec un«backlog»(liste des besoins en attente). C’est une forme de planification en 
vagues (rolling wave planning) fondee sur des cycles de vie adaptatifs, comme I’approche agile pour I’elaboration 
du produit. Les exigences sont documentees dans des scenarii d’utilisateurs (user stories) classes par ordre de 
priorite, puis affines juste avant la construction. Les fonctionnalites du produit sont, quant a elles, developpees au 
moyen de periodes de travail delimitees. Cette approche est souvent utilisee pour offrir une valeur incrementielle 
au client ou lorsque plusieurs equipes peuvent simultanement developper un grand nombre de fonctionnalites 
ayant quelques dependances liees. La methode de planification est appropriee pour de nombreux projets, comme 
I'indique I’utilisation repandue et croissante des cycles de vie adaptatifs pour le developpement de produits. 
Cette methode presente I'avantage d’accueillir les changements tout au long du cycle de vie du developpement. 

♦ Planification a la demande. Cette approche, habituellement utilisee dans un systeme Kanban et destinee 
a limiter un travail d’equipe en cours en vue d’equilibrer la demande par rapport a la cadence de livraison de 
I’equipe, repose sur la theorie de planification fondee sur la demande et les contraintes du lean manufacturing. 
La planification a la demande ne repose pas sur un echeancier elabore en amont du developpement du produit ou 
des increments du produit, mais genere le travail a partir d’une liste de besoins en attente (backlog) ou d’une liste 
de taches a effectuer immediatement des la mise a disposition des ressources. La planification a la demande 
est souvent utilisee pour les projets qui incrementent le produit dans des environnements d’exploitation ou de 
preservation et lorsque des taches sont relativement similaires en termes de taille et de perimetre ou peuvent 
etre regroupees en fonction de leur taille et de leur perimetre. 


177 



CONSIDERATIONS RELATIVES A L’ADAPTATION 

Chaque projet etant unique, il peut s’averer necessaire pour le chef de projet d’adapter la fagon dont les processus 
de gestion de I’echeancier du projet sont appliques. Parmi les considerations relatives a I’adaptation, on peut citer les 
elements suivants: 

♦ Approche du cycle de vie. Quelle est I’approche du cycle de vie la plus appropriee offrant un echeancier 
plus detaille ? 

♦ Disponibilite des ressources. Quels facteurs influent sur les durees (comme la correlation entre les ressources 
disponibles et leur productivite) ? 

♦ Dimension du projet. Comment la complexite du projet, I’incertitude technologique, la nouveaute du produit, le 
suivi de la cadence ou de I’avancement (comme la valeuracquise, le pourcentage d’avancement, les indicateurs 
rouge-jaune-vert [feu tricolore]) influent-ils sur le niveau de controle souhaite ? 

♦ Soutien technologique. La technologie est-elle utilisee pour elaborer, enregistrer, transmettre, recevoir et 
conserver les informations du modele d’echeancier du projet ? Est-elle immediatement accessible ? 

Pour plus d'informations specifiques a I’echeancier, voir le Practice Standard for Scheduling [16]. 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les approches adaptatives utilisent des cycles courts pour entreprendre le travail, passer en revue les resultats 
et s'adapter si necessaire. Ces cycles offrent un retour d’information rapide sur les approches et la pertinence des 
livrables. Ms prennent generalement la forme d’une planification iterative et d’une planification a la demande, en 
fonction des besoins, comme aborde dans la section sur les tendances principales et les pratiques emergentes en 
gestion de I’echeancier du projet. 

Dans les grandes organisations, il peut y avoir une combinaison de petits projets et de grandes initiatives 
necessitant des feuilles de route a long terme pour gerer le developpement des programmes utilisant des facteurs 
d’echelle (par exemple, la taille de I'equipe, la repartition geographique, la conformite reglementaire, la complexite 
organisationnelle et la complexite technique). Pour traiter I’integralite du cycle de vie de livraison de systemes plus 
grands a I’echelle de I’organisation, il peut s'averer necessaire d’adopter plusieurs techniques utilisant une approche 
predictive, une approche adaptative ou une combinaison des deux. L’organisation devra sans doute associer les 
pratiques de plusieurs methodes de base ou adopter une methode eprouvee ainsi que quelques principes et pratiques 
plus traditionnels. 

Le role du chef de projet ne change pas selon qu’il gere des projets a I'aide d’un cycle de vie predictif ou dans des 
environnements adaptatifs. Cependant, pour bien appliquer des approches adaptatives, le chef de projet devra se 
familiariser avec les outils et les techniques afin de comprendre comment les utiliser de maniere efficace. 
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6.1 PLANIFIER LA GESTION DE I’ECHEANCIER 


Planifier la gestion de I’echeancier est le processus qui consiste a etablir les politiques internes, les procedures et 
la documentation pour la planification, le developpement, la gestion, la realisation et la maTtrise de I'echeancier du 
projet. L'interet principal de ce processus est qu’il fournit les directives et les orientations de gestion de I’echeancier 
du projet tout au long du projet. Ce processus est execute au moins une fois ou a plusieurs moments predefinis 
durant le projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont 
represents sur la figure 6-3. La figure 6-4 represente le diagramme de flux de donnees du processus. 


Planifier la gestion de I’echeancier 


Donnees d’entree 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion du perimetre 

• Approche 

de developpement 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

v___y 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Analyse des donnees 
.3 Reunions 

v_y 


Donnees de sortie 


.1 Plan de gestion 


de I'echeancier 


V 

_y 


Figure 6-3. Planifier la gestion de I’echeancier: donnees d’entree, outils, techniques et donnees de sortie 



• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 6-4. Planifier la gestion de I’echeancier: diagramme de flux de donnees 
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6.1.1 PLANIFIER LA GESTION DE L’ECHEANCIER : DONNEES D’ENTREE 


6.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet specifie I’echeancier resume des jalons qui aura une influence 
sur la gestion de I'echeancier du projet. 

6.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre et du contenu. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre 
et du contenu decrit la maniere dont le perimetre et le contenu seront definis et elabores, ce qui fournira des 
informations sur la methode d’elaboration de I’echeancier. 

♦ Approche de developpement. Elle est decrite a la section 4.2.3.1. L’approche de developpement du produit 
aidera a definir I’approche de planification, les techniques d’estimation, les outils de planification et les techniques 
de maitrise de I’echeancier. 

6.1.1.3 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion de I’echeancier, on peut citer: 

♦ la culture et la structure organisationnelles ; 

♦ la disponibilite et les competences des ressources de I’equipe, ainsi que la disponibilite des ressources physiques; 

♦ les logiciels de planification ; 

♦ les directives et les criteres d’adaptation de I’ensemble des procedures et des processus standards de 
I’organisation, pour satisfaire les besoins particulars du projet; 

♦ les bases de donnees commerciales, telles que les donnees d'estimation standardises. 

6.1.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion de I’echeancier, 
on peut citer: 

♦ les donnees historiques et les archives de retours d'experience ; 

♦ les politiques, les procedures et les instructions existantes, formelles et informelles, relatives a I’elaboration, a la 
gestion et a la maitrise de I’echeancier; 

♦ les modeles et les formulaires ; 

♦ les outils de martrise et de communication. 
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6.1.2 PLANIFIER LA GESTION DE L’ECHEANCIER : OUTILS ET TECHNIQUES 


6.1.2.1 JUGEMENTA DIRE D’EXPERT 

II convient de faire appel a la competence decrite a la section 4.1.2.1 de personnes ou de groupes ayant une 
connaissance specialist ou une formation aux projets anterieurs similaires : 

♦ elaboration, gestion et maTtrise de I'echeancier; 

♦ methodologies de planification (cycle de vie adaptatif ou predictif); 

♦ logiciels de planification ; 

♦ secteur d’activite specifique au projet. 

6.1.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figure notamment I’analyse 
des alternatives. L'analyse des alternatives peut inclure le choix de la methodologie de planification ou la combinaison 
de plusieurs methodes dans le cadre du projet. Elle peut egalement permettre de determiner le niveau de precision 
de I'echeancier, la duree des vagues pour une planification en vagues ainsi que la frequence des revues et des mises 
a jour. Pour chaque projet, il convient de trouver le bon equilibre entre le niveau de detail necessaire pour gerer 
I’echeancier et le temps necessaire pour le tenir a jour. 

6.1.2.3 REUNIONS 

Les equipes projet peuvent tenir des reunions de planification dans le but d’elaborer le plan de gestion de I’echeancier. 
Les participants a ces reunions peuvent compter le chef et le sponsor du projet, des membres selectionnes de I’equipe 
projet, certaines des autres parties prenantes, toute personne ayant une responsabilite de planification ou d’execution 
de I’echeancier ainsi que d’autres personnes, selon les besoins. 


6.1.3 PLANIFIER LA GESTION DE L’ECHEANCIER : DONNEES DE SORTIE 

6.1.3.1 PLAN DE GESTION DE L’ECHEANCIER 

Le plan de gestion de I'echeancier est un composant du plan de management du projet qui etablit les criteres 
et les activites pour I'elaboration et la maTtrise de I'echeancier. II peut etre formel ou informel, tres detaille ou 
formule de maniere generate, en fonction des besoins du projet, et comprend les seuils de controle appropries. 
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Le plan de gestion de I’echeancier permet, par exemple, d’etablir les elements suivants: 

♦ Elaboration du modele d’echeancier du projet. La methodologie et I’outil de planification a utiliser pour 
I’elaboration du modele d’echeancier du projet sont specifies. 

♦ Duree des releases et des iterations. En cas d’utilisation d’un cycle de vie adaptatif, des periodes de temps 
delimitees sont specifies pour les releases, les vagues et les iterations. Les periodes de temps delimitees 
sont des durees pendant lesquelles I'equipe travaille de maniere continue afin d’atteindre un objectif. Elies 
permettent de minimiser la derive du perimetre (scope creep) puisqu’elles poussent I’equipe a traiter d’abord les 
caracteristiques essentielles et ensuite les autres caracteristiques, en fonction du temps restant. 

♦ Niveau d’exactitude. La fourchette acceptable, permettant de determiner des estimations realistes de la duree 
des activites, est specifiee et peut comprendre une provision pour aleas. 

♦ Unites de mesure. Chacune des unites de mesure utilisees sera definie pour chacune des ressources (par 
exemple, les heures et les jours-homme mais aussi les semaines pour la mesure du temps; les metres, les litres, 
les tonnes, les kilometres et les metres cubes pour les mesures de quantite). 

♦ Liens avec les procedures de (’organisation. L’organigramme des travaux du projet (work breakdown structure, 
WBS) (voir la section 5.4) fournit le cadre du plan de gestion de I'echeancier, en permettant la coherence des 
estimations et des echeanciers qui en resultent. 

♦ Maintenance du modele d’echeancier du projet. II s’agit du processus de mise ajour de I’etat et d'enregistrement 
de I'avancement du projet dans le modele d’echeancier pendant I’execution du projet. 

♦ Seuils de controle. Des seuils d’ecarts peuvent etre specifies pour la martrise de la performance de I’echeancier, 
de fagon a preciser un niveau d’ecart convenu comme acceptable avant qu’une action ne devienne necessaire. 
Ces seuils sont habituellement exprimes en pourcentage d’ecart par rapport aux parametres fixes dans le plan 
de reference de base. 

♦ Regies de mesure de performance. Les regies de mesure de performance sont etablies grace a la gestion de 
la valeur acquise (EVM) ou d’autres regies de mesure physique. Le plan de gestion de I’echeancier peut specifier, 
par exemple: 

■ les regies pour etablir le pourcentage d’avancement; 

■ les techniques de gestion de la valeur acquise (EVM) a utiliser (par exemple, des references de base, des 
formules fixes et le pourcentage d’avancement) (Pour obtenir des informations plus specifiques sur la gestion 
de la valeur acquise, voir The Practice Standard for Earned Value Management [17].); 

■ les mesures de performance de I'echeancier, telles que les ecarts de delais (SV) et I’indice de performance 
des delais (SPI), qui permettent d’evaluer I’importance de I’ecart par rapport a la reference de base initiate 
de I’echeancier. 

♦ Formats des rapports. Les formats et la frequence des differents rapports sur I’echeancier sont definis. 
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6.2 DEFINIR LES ACTIVITES 


Definir les activites est le processus qui consiste a identifier et a documenter les actions specifiques a effectuer pour 
produire les livrables du projet. L’interet principal de ce processus est qu’il decompose les lots de travaux en activites 
de I'echeancier qui servent de base a I'estimation, a la planification, a I'execution, a la martrise du travail du projet. Ce 
processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de 
ce processus sont represents sur la figure 6-5. La figure 6-6 represente le diagramme de flux de donnees du processus. 


Definir les activites 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
du perimetre 

.2 Facteurs environnementaux 
de I'organisation 
.3 Actifs organisationnels 
V 


.1 Jugement a dire d'expert 
.2 Decomposition 
.3 Planification en vagues 
.4 Reunions 

V_ ) 


.1 Liste d'activites 
.2 Attributs des activites 
.3 Liste des jalons 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

V_ 


Figure 6-5. Definir les activites : donnees d’entree, outils, techniques et donnees de sortie 



• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 



• Reference de base 
des couts 


Figure 6-6. Definir les activites: diagramme de flux de donnees 
























































6.2.1 DEFINIR LES ACTIVITES : DONNEES D’ENTREE 


6.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I'echeancier definit la 
methodologie de construction de I’echeancier, la duree des vagues pour la planification en vagues et le niveau 
de detail necessaire pour gerer le travail. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Le WBS, les livrables, les contraintes 
et les hypotheses du projet, documents dans la reference de base du perimetre du projet, sont explicitement 
considers lors de la definition des activites. 

6.2.1.2 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de ^organisation qui ont une influence sur le processus Definir les activites, on 
peut citer: 

♦ les cultures et la structure organisationnelles; 

♦ les informations commerciales publiees provenant de bases de donnees commerciales; 

♦ le systeme d'information de management du projet (PMIS). 

6.2.1.3 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Definir les activites, on peut citer: 

♦ I’archive des retours d’experience, contenant les donnees historiques relatives aux listes d’activites utilisees 
dans des projets anterieurs similaires; 

♦ les processus standardises ; 

♦ les modeles contenant une liste d’activites standardises ou une partie d’une liste d’activites provenant d’un 
projet anterieur; 

♦ les politiques, les procedures et les directives existantes, formelles et informelles, liees a la planification des 
activites, telle que la methodologie d’elaboration de I'echeancier, qui sont prises en compte lors de la definition 
des activites. 

6.2.2 DEFINIR LES ACTIVITES : OUTILS ET TECHNIQUES 
6.2.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist de projets anterieurs similaires et du travail en cours d’execution. 
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6.2.2.2 DECOMPOSITION 

Elle est decrite a la section 5.4.2.2. La decomposition est une technique utilisee pour diviser et subdiviser le perimetre 
et les livrables du projet en elements plus petits et plus faciles a gerer. Les activites represented I’effort necessaire a 
I'achevement d’un lot de travaux. Le processus Definir les activites definit les donnees de sortie finales comme etant 
des activites et non pas des livrables, contrairement au processus Creer le WBS (voir la section 5.4). 

La liste d'activites, le WBS et le dictionnaire du WBS peuvent etre developpes sequentiellement ou en parallele, le 
WBS et le dictionnaire du WBS servant de base a I'etablissement de la liste finale d’activites. Chacun des lots de travaux 
du WBS est decompose en activites necessaires a la production des livrables de ce lot de travaux. La participation des 
membres de I'equipe projet a cette decomposition peut permettre d’obtenir des resultats meilleurs et plus exacts. 

6.2.2.3 PLANIFICATION EN VAGUES 

La planification en vagues est une technique de planification iterative selon laquelle les travaux a realiser a court 
terme sont planifies en detail, tandis que les travaux a plus long terme le sont de maniere plus generate. C’est une 
forme d’elaboration progressive applicable aux lots de travaux, aux lots de planification eta la planification des releases 
en cas d’utilisation d’une approche agile ou de type waterfall. Par consequent, le travail peut etre presente de maniere 
plus ou moins detaillee selon sa position dans le cycle de vie du projet. Au cours de la periode initiale de planification 
strategique, alors que I’information est moins detaillee, les lots de travaux peuvent etre decomposes au niveau de 
detail connu.Avec une meilleure connaissance des evenements qui vontse produire dans un avenir proche, ces lots de 
travaux pourront alors etre decomposes en activites. 

6.2.2.4 REUNIONS 

Les reunions peuvent etre en face a face, virtuelles, formelles ou informelles. Des membres de I’equipe ou des 
experts d’un domaine specifique peuvent se reunir pour definir les activites necessaires a la realisation du travail. 


6.2.3 DEFINIR LES ACTIVITES : DONNEES DE SORTIE 

6.2.3.1 LISTE D’ACTIVITES 

La liste d’activites inclut toutes les activites de I’echeancier necessaires au projet. Pour les projets qui utilisent une 
planification en vagues ou des techniques agiles, la liste d’activites est revisee regulierement a mesure que le projet 
avance. Cette liste d’activites inclut les identifiants des activites et, pour chacune des activites, une description du 
perimetre de travail suffisamment detaillee pour permettre aux membres de I’equipe projet de comprendre le travail 
qu’il est necessaire d’accomplir. 
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6.2.3.2 ATTRIBUTS DES ACTIVITES 

Les attributs des activites completent la description de celles-ci en identifiant les multiples composants associes 
a chacune d’entre elles. Les composants de chaque activite evoluent dans le temps. Pendant les premieres phases 
du projet, ils comprennent I'identifiant unique de chaque activite, I'identifiant du WBS et le nom ou le libelle de 
I'activite. A la fin, ils peuvent inclure les descriptions des activites, les activites predecesseurs et successeurs, les 
liens logiques, les avances et les retards (voir la section 6.3.2.3), les besoins en ressources, les dates imposees, les 
contraintes et les hypotheses. Les attributs des activites peuvent etre utilises pour identifier I’endroit ou le travail doit 
etre accompli, le calendrier du projet correspondant a I’activite et le type d’effort implique. Les attributs des activites 
sont utilises pour elaborer I’echeancier et pour selectionner, classer et trier de differentes manieres dans les rapports 
les activites planifiees de I'echeancier. 

6.2.3.3 LISTE DES JALONS 

Un jalon est un point ou un evenement important d’un projet. Une liste des jalons identifie tous les jalons et precise, 
pour chacun d’eux, s’ils sont obligatoires, comme ceux requis par contrat, ou facultatifs, lorsqu’ils sont bases sur des 
donnees historiques. Les jalons n’ont pas de duree puisqu’ils represented un point ou un evenement important. 

6.2.3.4 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Une fois que le projet est fonde sur des references de base, I’elaboration 
progressive des livrables au sein des activites peut reveler des travaux qui ne faisaient initialement pas partie des 
references de base du projet, ce qui peut generer une demande de changement. Les demandes de changementsont 
passees en revue et traitees par le processus MaTtriser les changements (voir la section 4.6). 

6.2.3.5 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. Tout au long du projet, des lots de 
travaux sont progressivement detailles en activites. Ce processus peut reveler des travaux qui ne faisaient 
initialement pas partie de la reference de base de I'echeancier, ce qui necessite de changer les dates de livraison 
ou tout autre jalon de I'echeancier important figurant dans la reference de base de I'echeancier. 

♦ Reference de base des coufs. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference de 
base des couts sont incorpores a la suite des changements approuves des activites de I’echeancier. 
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6.3 ORGANISER LES ACTIVITES EN SEQUENCE 


Organiser les activites en sequence est le processus qui consiste a identifier et a documenter les relations entre 
les activites du projet. L’interet principal de ce processus est qu’il definit la sequence logique de travail pour obtenir 
I’efficacite maximale compte tenu de toutes les contraintes du projet. Ce processus est execute tout au long du projet. 
Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la 
figure 6-7. La figure 6-8 represente le diagramme de flux de donnees du processus. 


Organiser les activites en sequence 


Donnees d’entree 


.1 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Liste des jalons 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V___/ 


Outils et techniques 


.1 Methode des antecedents 
.2 Determination et integration 
des dependences 
.3 Avances et retards 
.4 Systeme d’information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

V___ J 


Donnees de sortie 


.1 Diagrammes de reseau 
du projet 

.2 Mises a jour des documents 
du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Liste des jalons 

V___/ 


Figure 6-7. Organiser les activites en sequence: donnees d’entree, outils, techniques et donnees de sortie 


Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion de I’echeancier 

• Reference de base du perimetre 


Documents 
du projet 


Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Liste des jalons 


Entreprise/ 

Organisation 


6.3 

Organiser 
les activites 
en sequence 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 



Mises a jour des documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Liste des jalons 


Figure 6-8. Organiser les activites en sequence: diagramme de flux de donnees 
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Chaque activite, a I’exception de la premiere et de la derniere, doit etre reliee a une activite predecesseur et une 
activite successeur au moins a I’aide d’un lien logique approprie. Les liens logiques doivent etre congus pour creer un 
echeancier de projet realiste. II peut etre necessaire de placer entre les activites une avance ou un retard, de fagon a 
etablir un echeancier du projet realiste et faisable. L'organisation d’activites en sequence peut etre effectuee a I’aide 
d’un logiciel de management de projet ou bien de techniques manuelles ou automatisees. Le processus Organiser les 
activites en sequence est axe sur la conversion d’une liste vers un diagramme des activites du projet et sert de premiere 
etape a la publication de la reference de base de I’echeancier. 


6.3.1 ORGANISER LES ACTIVITES EN SEQUENCE : DONNEES D’ENTREE 

6.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de i’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I’echeancier definit la 
methode utilisee et le niveau d’exactitude, ainsi que d'autres criteres requis pour organiser les activites en sequence. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Le WBS, les livrables, les contraintes 
et les hypotheses du projet, documents dans la reference de base du perimetre du projet, sont explicitement 
consideres lors de l’organisation des activites en sequence. 

6.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre consideres comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Attributs des activites. Ils sont decrits a la section 6.2.3.2. Les attributs des activites peuvent decrire une 
sequence d’evenements necessaire ou de liens definis avec une activite predecesseur ou successeur ainsi que 
les liens logiques, les avances et les retards entre les activites. 

♦ Liste d’activites. Elle est decrite a la section 6.2.3.1. La liste d’activites contient toutes les activites de I’echeancier 
necessaires au projet qui doivent faire I’objet du sequencement. Les dependances et d’autres contraintes pour 
ces activites peuvent influencer le sequencement des activites. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Les hypotheses et les contraintes enregistrees dans le 
journal des hypotheses peuvent avoir une influence sur le sequencement des activites, le lien entre les activites 
et la necessity d’avances ou de retards. Elies peuvent egalement generer des risques de projet individuels 
susceptibles d'influer sur I’echeancier du projet. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons peut specifier des dates pour certains 
jalons, ce qui est susceptible d’avoir une influence sur le sequencement des activites. 
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6.3.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Organiser les 
activites en sequence, on peut citer: 

♦ les standards gouvernementaux ou industriels; 

♦ le systeme d'information de management du projet (PMIS); 

♦ I'outil de planification ; 

♦ les systemes d’autorisation des travaux de I'organisation. 

6.3.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Organiser les activites en sequence, 
on peut citer: 

♦ les plans du portefeuille ou du programme, mais aussi les dependances et les liens du projet; 

♦ les politiques, les procedures et les directives existantes, formelles et informelles, liees a la planification des activites, 
telle que la methodologie de planification, qui sont prises en compte lors de I'elaboration des liens logiques; 

♦ les modeles pouvant etre utilises pour accelerer la preparation de reseaux pour les activites du projet; dans les 
modeles, les informations sur les attributs des activites susceptibles egalement d'inclure d’autres informations 
descriptives utiles au sequencement des activites; 

♦ I’archive des retours d’experience contenant des donnees historiques qui peuvent permettre d’optimiser le 
processus de sequencement. 

6.3.2 ORGANISER LES ACTIVITES EN SEQUENCE : OUTILS ET TECHNIQUES 

6.3.2.1 METHODE DES ANTECEDENTS (PRECEDENCE DIAGRAMMING METHOD, PDM) 

La methode des antecedents (PDM) est une technique utilisee pour la construction d’un modele d’echeancier dans 
lequel les activites sont representees par des noeuds et sont graphiquement liees par un ou plusieurs liens logiques, 
pour montrer I’ordre dans lequel les activites devront etre effectuees. 

La methode des antecedents comprend quatre types de dependance ou de lien logique. Dans un echeancier, une 
activite predecesseur est une activite qui precede logiquement une activite dependante. Une activite successeur est une 
activite dependante qui vient logiquement apres une autre activite dans un echeancier. Ces liens sont definis ci-dessous 
et sont illustres a la figure 6-9 : 
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♦ Liaison fin-debut. Lien logique dans lequel une activite successeur ne peut pas commencer tant qu’une activite 
predecesseur n’est pas achevee. Par exemple, (’installation du systeme d’exploitation sur un PC (successeur) ne 
peut demarrer tant que le PC n’est pas monte (predecesseur). 

♦ Liaison fin-fin. Lien logique dans lequel une activite successeur ne peut pas se terminer tant qu’une activite 
predecesseur n’est pas achevee. Par exemple, la redaction d’un document (predecesseur) doit avoir ete terminee 
pour que I'edition (successeur) puisse commencer. 

♦ Liaison debut-debut. Lien logique dans lequel une activite successeur ne peut pas commencer avant qu’une 
activite predecesseur n'ait commence. Par exemple, le lissage du beton (successeur) ne peut commencer avant 
que le coulage des fondations (predecesseur) ne commence. 

♦ Liaison debut-fin. Lien logique dans lequel une activite successeur ne peut pas se terminer avant qu’une 
activite predecesseur n'ait commence. Par exemple, un nouveau systeme de comptes fournisseurs (successeur) 
doit etre mis en place avant que I’ancien systeme de comptes fournisseurs ne soit arrete (predecesseur). 

La liaison fin-debut est la relation d’anteriorite la plus communement utilisee dans la methode des antecedents. 
La liaison debut-fin, bien que rarement utilisee, est mentionnee de fagon a presenter une liste complete des types de 
liaisons reposant sur la methode des antecedents. 

Deux activites peuvent avoir deux liens logiques en meme temps (par exemple, une liaison debut-debut et une liaison 
fin-fin). Les liaisons multiples entre les memes activites sont deconseillees. II convient done de choisir la liaison ayant 
le plus grand impact. Les boucles fermees ne sont pas recommandees dans les liens logiques. 



Figure 6-9. Types de liaison reposant sur la methode des antecedents (PDM) 
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6.3.2.2 DETERMINATION ET INTEGRATION DES DEPENDANCES 


Les dependances peuvent etre caracterisees par les attributs suivants : obligatoire, facultative, interne ou externe 
(comme decrit ci-dessous). La dependance a quatre attributs, mais deux d’entre eux peuvent etre applicables 
simultanement comme decrit ci-apres : les dependances externes obligatoires, les dependances internes obligatoires, 
les dependances externes facultatives ou les dependances internes facultatives. 

♦ Dependances obligatoires. Les dependances obligatoires sont celles qui sont legalement ou contractuellement 
exigees ou inherentes a la nature du travail. Les dependances obligatoires mettent souvent en jeu des limitations 
physiques comme dans le cadre d’un projet de construction, ou Ton ne peut pas eriger une superstructure 
tant que les fondations n’ont pas ete realisees, ou encore dans le cadre d’un projet en electronique, ou un 
prototype doit etre construit avant que I'on puisse le tester. On utilise parfois les expressions «logique forte » 
ou « dependances fortes » pour qualifier les dependances obligatoires. Les dependances techniques ne sont 
pas forcement obligatoires. Les dependances obligatoires sont determinees par I'equipe projet au cours du 
processus Organiser les activites en sequence. Les dependances obligatoires ne doivent pas etre confondues 
avec I’affectation de contraintes d’echeancier dans I'outil de planification. 

♦ Dependances facultatives. Les dependances facultatives sont souvent designees par les expressions «liens 
logiques preferes »,«liens logiques preconises » ou «liens logiques faibles ». Leur etablissement est base sur 
la connaissance des meilleures pratiques dans un champ d’application donne ou sur certaines particularites du 
projet pour lequel une sequence particuliere est souhaitee, meme si d’autres sequences sont envisageables. Par 
exemple, les meilleures pratiques generalement admises recommandent que, pendant la construction, les travaux 
electriques demarrent une fois les travaux de plomberie acheves. Cet ordre n’est pas obligatoire et les deux 
activites peuvent etre accomplies en meme temps (en parallele), mais I’execution des activites dans un certain 
ordre permet de reduire le risque global du projet. Les dependances optionnelles doivent etre completement 
documentees, car elles peuvent creer des valeurs arbitraires de marge totale et limiter ulterieurement les options 
de planification. Lorsqu'on utilise des techniques de mise en parallele, ces dependances optionnelles doivent etre 
passees en revue et on doit envisager de les modifier ou de les supprimer. Les dependances optionnelles sont 
determinees par I’equipe projet au cours du processus Organiser les activites en sequence. 
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♦ Dependances externes. Les dependances externes mettent en jeu un lien entre des activites du projet et 
d’autres activites qui n’en font pas partie. Ces dependances ne sont generalement pas sous le controle de 
I’equipe projet. Par exemple, les activites de test d’un projet de developpement de logiciel peuvent dependre 
de la livraison du materiel par un fournisseur externe ou, dans un projet de construction, des auditions 
gouvernementales publiques sur I’environnement doivent etre organisees avant de commencer la preparation du 
site. Les dependances externes sont determinees par I’equipe de management de projet au cours du processus 
Organiser les activites en sequence. 

♦ Dependances internes. Les dependances internes mettent en jeu une relation d’anteriorite entre des activites 
du projet et sont, en regie generale, sous la maTtrise de I’equipe projet. Par exemple, si I’equipe n’est pas en 
mesure de tester une machine avant qu’elle ne soit assemblee, il s’agit d’une dependance obligatoire interne. 
Les dependances internes sont determinees par I’equipe de management de projet au cours du processus 
Organiser les activites en sequence. 

6.3.2.3 AVANCES ET RETARDS 

Une avance est la duree dont une activite successeur peut etre avancee par rapport a une activite predecesseur. 
Par exemple, dans un projet de construction d’un nouvel immeuble de bureaux, I’amenagement de I'espace paysager 
pourrait demarrer deux semaines avant I’achevement du traitement de la liste des reserves. Cette possibility serait 
illustree par une liaison fin-debut avec une avance de deux semaines comme presente sur la figure 6-10. L'avance est 
souvent representee comme une valeur negative de retard dans les logiciels de planification. 



Figure 6-10. Exemples d’avance et de retard 
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Un retard est la duree dont une activite successeur doit etre retardee par rapport a une activite predecesseur. Par 
exemple, une equipe de redaction technique peut demarrer I'edition de la version preliminaire d’un document volumineux 
15 jours apres avoir commence a I’ecrire. Cette possibility peut etre illustree par une liaison debut-debut avec un retard 
de 15 jours, comme le montre la figure 6-10. Le retard peut egalement etre represente sur les diagrammes de reseau du 
projet, comme a la figure 6-11, dans la liaison entre les activites Wet /, indique par la nomenclature DD+10 (debut-debut 
plus 10 jours de retard) bien que le decalage ne soit pas represente par rapport a une echelle de temps. 

L’equipe de management de projet determine les dependances pouvant necessiter une avance ou un retard pour 
definir avec precision le lien logique. L’utilisation des avances ou des retards ne doit pas remplacer la logique de 
I’echeancier. En outre, les estimations de durees n’integrent aucune avance ni aucun retard. II est necessaire de 
documenter les activites et leurs hypotheses associees. 



Figure 6-11. Diagramme de reseau du projet 


6.3.2.4 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d’information de management du projet incluent les logiciels de 
planification qui permettent de planifier, d’organiser et d'ajuster le sequencement des activites, d’inserer les liens 
logiques, les valeurs des avances et des retards, mais aussi de differencier les differents types de dependances. 
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6.3.3 ORGANISER LES ACTIVITES EN SEQUENCE : DONNEES DE SORTIE 


6.3.3.1 DIAGRAMMES DE RESEAU DU PROJET 

Un diagramme de reseau du projet est une representation graphique des liens logiques, aussi appeles dependances, 
entre les activites de I'echeancier du projet. La figure 6-11 represente un diagramme de reseau du projet. Un diagramme 
de reseau du projet peut etre developpe manuellement ou a I’aide d’un logiciel de management de projet. II peut inclure 
tous les details du projet ou bien une voire plusieurs consolidations d’activites. Une note recapitulative peut accompagner 
le diagramme et decrire I'approche de base utilisee pour organiser les activites en sequence. Toutes les sequences 
d’activites inhabituelles qui se trouvent a I’interieur du reseau doivent etre completement decrites dans cette note. 

Les activites liees a plusieurs activites predecesseurs indiquent une convergence des chemins. Les activites liees a 
plusieurs activites successeurs indiquent une divergence des chemins. Les activites indiquant une divergence et une 
convergence presented un risque plus eleve, car elles sont concernees par plusieurs activites ou peuvent concerner 
plusieurs activites. L'activite I est appelee convergence des chemins, car elle est liee a plusieurs activites predecesseurs, 
tandis que l’activite K est appelee divergence des chemins, car elle est liee a plusieurs activites successeurs. 

6.3.3.2 MISE A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Attributs des activites. Ms sont decrits a la section 6.2.3.2. Les attributs des activites peuvent decrire une 
sequence d'evenements necessaire ou des liens definis avec une activite predecesseurou successeurainsi que 
les liens logiques, les avances et les retards entre les activites. 

♦ Liste d’activites. Elle est decrite a la section 6.2.3.1. La liste d’activites peut etre influencee par le changement 
des liens entre les activites du projet au cours de I'organisation des activites en sequence. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. En fonction du sequencement, du lien entre les 
activites, des avances ou des retards, il peut s'averer necessaire de mettre a jour les hypotheses et les contraintes 
consignees dans le registre des hypotheses, lesquelles sont susceptibles de generer des risques de projet 
individuels pouvant influer sur I’echeancier du projet. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. Les dates prevues pour des jalons specifiques peuvent 
etre influences par le changement des liens entre les activites du projet au cours de I'organisation des activites 
en sequence. 
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6.4 ESTIMER LA DUREE DES ACTIVITES 


Estimer la duree des activites est le processus qui consiste a estimer le nombre de periodes de travail requises pour 
accomplir chacune des activites avec leurs ressources estimees. L’interet principal de ce processus est qu’il chiffre 
le temps necessaire pour mener a bien chacune des activites. Ce processus est execute tout au long du projet. Les 
donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont represents sur la figure 6-12. 
La figure 6-13 represente le diagramme de flux de donnees du processus. 


Estimer la duree des activites 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Registre des retours 
d'experience 

• Liste des jalons 

• Affectations des membres 
de I'equipe projet 

• Organigramme 
des ressources 

• Calendriers des ressources 

• Besoins en ressources 

• Registre des risques 

.3 Facteurs environnementaux 

de I'organisation 

.4 Actifs organisationnels 

V___y 


.1 Jugement a dire d'expert 
.2 Estimation par analogie 
.3 Estimation parametrique 
.4 Estimation a trois points 
.5 Estimation ascendante 
.6 Analyse des donnees 

• Analyse des alternatives 

• Analyse de la reserve 
.7 Prise de decision 

.8 Reunions 

v_y 


.1 Estimations de durees 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

• Attributs des activites 

• Journal des hypotheses 

• Registre des retours 
d'experience 

v___y 


Figure 6-12. Estimer la duree des activites: donnees d’entree, outils, techniques et donnees de sortie 
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Plan de management du projet 

• Plan de gestion de I’echeancier 

• Reference de base du perimetre 
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Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Registre des retours d’experience 

• Liste des jalons 

• Affectations des membres 
de I’equipe projet 

• Organigramme des ressources 

• Calendriers des ressources 

• Besoins en ressources 

• Registre des risques 
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• Estimations de durees 

• Base des estimations 
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Mises a jour des documents du projet 

• Attributs des activites 

• Journal des hypotheses 

• Registre des retours d'experience 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 6-13. Estimer la duree des activites : diagramme de flux de donnees 


L'estimation de la duree des activites utilise les informations sur le perimetre du travail de I'activite, les types de 
ressources ou les niveaux de competence necessaires, les quantites de ressources estimees et les calendriers des 
ressources. D’autres facteurs peuvent avoir une influence sur les estimations de durees, notamment les contraintes 
imposees en termes de duree, les efforts engages ou le type de ressources (par exemple, la duree fixe, I’effort ou 
le travail fixe, le nombre fixe de ressources), ainsi que la technique d’analyse du diagramme de reseau utilisee. Les 
donnees d’entree de cette estimation proviennent de la personne ou du groupe de personnes de I’equipe projet qui 
connart le mieux la nature du travail requis pour chaque activite specifique. L’estimation de la duree est elaboree 
progressivement, et le processus tient compte de la qualite et de la disponibilite des donnees d’entree. Par exemple, la 
precision des estimations s'ameliore lorsque des donnees plus detaillees et plus precises deviennent disponibles sur un 
travail d'ingenierie et de conception. 
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Le processus Estimer la duree des activites necessite une estimation de I’effort de travail requis pour realiser I’activite 
ainsi que de la quantite de ressources disponibles necessaires a cette activite. Ces estimations sont utilisees pour avoir 
une approximation du nombre de periodes de travail (duree de I’activite) necessaires a la realisation de I’activite, en 
tenant compte des calendriers du projet et des ressources. Dans de nombreux cas, le nombre de ressources prevues 
pour realiser I'activite ainsi que leur niveau de competence peuvent determiner la duree de I'activite. Tout changement 
portant sur une ressource determinate allouee a I'activite aura generalement un effet sur la duree, mais le lien n’est 
ni direct ni lineaire. Parfois, la nature intrinseque du travail (par exemple, les contraintes imposees en termes de 
duree, I’effort engage ou le nombre de ressources) necessitera une duree predefine, quelle que soit la repartition des 
ressources (un test de resistance sur 24 heures, par exemple). Les autres facteurs a prendre en consideration pour 
estimer la duree sont notamment les suivants: 

♦ Loi des rendements decroissants. Lorsqu’un facteur (une ressource, par exemple) utilise pour determiner 
I’effort requis afin de produire une unite de travail est augmente alors que d'autres facteurs restent fixes, on 
atteint finalement un point ou les ajouts a ce facteur commencent progressivement a produire moins ou a 
diminuer les augmentations de productivite. 

♦ Nombre de ressources. Doubler le nombre de ressources ne permet pas toujours de reduire la duree de moitie, 
car elle peut etre augmentee en raison du risque. A certains stades, ajouter un trop grand nombre de ressources 
a I'activite peut augmenter la duree a cause du transfert de connaissances, de la courbe d’apprentissage, de la 
coordination supplemental et d’autres facteurs impliques. 

♦ Evolutions technologiques. Elies peuvent egalement jouer un role important dans la determination des 
estimations de durees. Par exemple, une usine peut augmenter sa productivite grace aux dernieres evolutions 
technologiques, qui peuvent avoir une influence sur la duree et les besoins en ressources. 

♦ Motivation du personnel. Le chef de projet doit egalement etre conscient du syndrome de I’etudiant, ou 
procrastination, lorsque les individus ne se mettent au travail qu'au tout dernier moment avant I'expiration du 
delai, mais aussi de la loi de Parkinson lorsque le travail augmente pour occuper entierement le temps qui lui 
est affecte. 

Toutes les donnees et toutes les hypotheses qui aident a I’estimation de la duree sont documentees pour chaque 
estimation de la duree d’une activite. 
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6.4.1 ESTIMER LA DUREE DES ACTIVITES : DONNEES D’ENTREE 


6.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I'echeancier definit la 
methode utilisee et le niveau de detail, ainsi que d’autres criteres requis pour estimer la duree des activites. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre inclut 
le dictionnaire du WBS, qui comprend des details techniques pouvant influer sur les estimations de durees 
et d’ effort. 

6.4.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Attributs des activites. Ils sont decrits a la section 6.2.3.2. Les attributs des activites peuvent decrire des liens 
definis avec une activite predecesseurou successeur ainsi que les liens logiques, les avances et les retards entre 
les activites susceptibles d’avoir un impact sur les estimations de durees. 

♦ Liste d’activites. Elle est decrite a lasection 6.2.3.1. La Iiste d’activites enumere toutes les activites de I'echeancier 
necessaires au projet, qui doivent faire I'objet de I’estimation. Les dependances et d’autres contraintes pour ces 
activites peuvent influencer I’estimation de durees. 

♦ Registre des hypotheses. II est decrit a la section 4.1.3.2. Les hypotheses et les contraintes consignees dans 
le journal des hypotheses peuvent generer des risques de projet individuels susceptibles d’avoir un impact sur 
I’echeancier du projet. 

♦ Registre des retours d’experience. II est decrit a la section 4.4. 3.1. Les retours d’experience du debut du projet, 
relatifs a I'estimation de la duree et de I’effort, peuvent etre appliques aux phases ulterieures afin d’ameliorer la 
precision des estimations. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons peut specifier des dates pour certains 
jalons, ce qui est susceptible d’avoir une influence sur les estimations de durees. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.1. Le projet est dote en 
personnel lorsque les personnes adequates ont ete affectees a I’equipe. 

♦ Organigramme des ressources. II est decrit a la section 9.2.3.3. L’organigramme des ressources fournit une 
structure hierarchique des ressources identifies et classees par categorie et par type. 
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♦ Calendriers des ressources. Ms sont decrits a la section 9.2.1.2. Les calendriers des ressources ont une 
influence sur la duree des activites de I'echeancier du fait de la disponibilite de ressources specifiques, du type 
de ressources et des ressources ayant des attributs particuliers. Les calendriers des ressources specified quand 
et pour quelle duree les ressources identifies seront disponibles pendant le projet. 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Les besoins estimes en ressources necessaires aux 
activites auront un impact sur la duree des activites, car le niveau d'allocation des ressources par rapport aux 
exigences influence de maniere significative la duree de la plupart des activites. Par exemple, si des ressources 
supplemental ou de moindres competences sont affectees a une activity, une reduction du rendement ou de 
la productivity peut survenir en raison d’un besoin accru en communication, formation et coordination, ce qui 
conduit a un allongement de la duree estimee. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Des risques de projet individuels peuvent affecter la 
selection et la disponibilite des ressources. Les mises a jour du registre des risques sont incluses dans les mises 
a jour des documents du projet decrites a la section 11.5.3.2 du processus Planifier les reponses aux risques. 

6.4.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Estimer la 
duree des activites, on peut citer: 

♦ les bases de donnees d’estimation de la duree et les autres donnees de reference; 

♦ les metriques de productivity; 

♦ les informations commerciales publiees ; 

♦ la localisation des membres de I’equipe. 

6.4.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Estimer la duree des activites, on 
peut citer: 

♦ les donnees historiques sur la duree; 

♦ les calendriers du projet; 

♦ les politiques d’estimation ; 

♦ la methodologie de planification ; 

♦ I’archive des retours d’experience. 
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6.4.2 ESTIMER LA DUREE DES ACTIVITES : OUTILS ET TECHNIQUES 


6.4.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ elaboration, gestion et maTtrise de I'echeancier; 

♦ expertise en estimation ; 

♦ connaissances de la discipline ou de I’application, 

6.4.2.2 ESTIMATION PAR ANALOGIE 

L'estimation par analogie est une technique d’estimation de la duree ou du cout d’une activite ou d’un projet 
en utilisant les donnees historiques d’une activite ou d’un projet similaire. L'estimation par analogie utilise les 
parametres d’un projet anterieur similaire, tels que la duree, le budget, la taille, la charge et la complexite, comme 
base pour l’estimation des memes parametres ou mesures dans un projet futur. Dans le cas des durees, cette 
technique utilise les durees reelles de projets anterieurs similaires comme bases d’estimation des durees du projet 
actuel. C’est une approche d’estimation grossiere qui est parfois ajustee pour tenir compte des differences de 
complexite entre projets. L'estimation par analogie de la duree est frequemment utilisee pour estimer la duree d’un 
projet lorsque Ton dispose de peu d’informations detaillees sur ce dernier. 

Le plus souvent, l'estimation par analogie est moins onereuse et prend moins de temps que les autres techniques, 
mais elle est egalement moins precise. Les estimations comparatives de la duree peuvent etre appliquees a un projet 
complet ou a des parties de projet et peuvent etre utilisees conjointement avec d’autres methodes d’estimation. 
L'estimation par analogie est d'autant plus fiable que les activites precedentes sont semblables, non seulement en 
apparence, mais surtout dans les faits, et que les membres de I'equipe projet realisant les estimations possedent 
I’expertise requise. 

6.4.2.3 ESTIMATION PARAMETRIQUE 

L’estimation parametrique est une technique d’estimation dans laquelle un algorithme est utilise pour calculer le cout 
ou la duree en se basant sur des donnees historiques et des parametres du projet. L'estimation parametrique utilise une 
relation statistique entre les donnees historiques et d’autres variables (par exemple, la superficie de construction en 
metres carres) pour estimer les parametres d’une activite, tels que le cout, le budget et la duree. 
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Les durees peuvent etre quantitativement determinees en multipliant la quantite de travail a effectuer par le nombre 
d’heures de travail par unite de travail. Par exemple, dans un projet de conception, la duree d’une activite est estimee 
en multipliant le nombre de dessins par le nombre d’heures de travail requises par dessin ou, pour un projet de cablage, 
en multipliant le metrage de cable par le nombre d’heures de travail par metre de cable. Si les ressources allouees 
sont capables d’installer 25 metres de cable par heure, la duree requise pour installer 1 000 metres de cable sera de 
40 heures (1 000 metres divises par 25 metres par heure). 

Cette technique permet d’obtenir des resultats d’un plus grand niveau d’exactitude, en relation avec la sophistication 
du modele et les donnees qu’il comporte. Les estimations parametriques de Pecheancier peuvent etre appliquees a un 
projet complet, ou a des parties d’un projet, et utilisees conjointement avec d’autres methodes d’estimation. 

6.4.2.4 ESTIMATION A TROIS POINTS 

L'exactitude des estimations de la duree d’une activite unique peut etre amelioree en prenant en compte I’incertitude et 
le risque de I'estimation. Les estimations a trois points permettent de definir la plage approximative de duree d’une activite: 

♦ Plus probable (dPP). Cette estimation est fonction de la duree de I'activite, compte tenu des ressources qui 
seront vraisemblablement affectees, de leur productivity, des attentes realistes de leur disponibilite pour cette 
activite, des dependences d’autres participants et des interruptions. 

♦ Optimiste (dO). La duree de I’activite est basee sur I’analyse du« meilleur scenario possible» pour I'activite. 

♦ Pessimiste (dF). La duree de I’activite est basee sur I’analyse du«pire scenario possible» pour I’activite. 

En fonction de la repartition supposee des valeurs contenues dans la plage des trois estimations, la duree estimee 
(dEj peut etre calculee a I’aide d’une formule. Une formule couramment utilisee est la distribution triangulaire: 

dE=(dO+ dPP+ dP)/3. 

La distribution triangulaire est utilisee lorsque les donnees historiques sont insuffisantes ou en cas d’utilisation de 
donnees subjectives. Les estimations de durees basees sur les trois points, avec une distribution definie, donnent une 
duree attendue et precisent la plage d'incertitude autour de cette duree. 
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6.4.2.5 ESTIMATION ASCENDANTE 


L'estimation ascendante est une methode d’estimation de la duree ou du cout du projet en agregeant les estimations 
des niveaux inferieurs du WBS. Lorsqu’il n’est pas possible d’estimer la duree d’une activite avec un niveau de confiance 
suffisant, le travail de cette activite est decompose plus en detail. Les durees detaillees sont estimees. Les estimations 
de durees de chacune des activites sont ensuite agregees en une quantite totale. Les activites peuvent presenter, ou 
non, des dependences entre elles, ce qui peut avoir un impact sur la designation et sur I’utilisation des ressources. 
Lorsque ces dependences existent, le schema d’utilisation des ressources est reflete et documents dans les besoins 
estimes pour ces activites. 

6.4.2.6 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. L'analyse des alternatives est utilisee pour comparer les differents niveaux de capacite 
ou de competence des ressources, les techniques de compression de I'echeancier (decrites a la section 6.5.2.6), 
les differents outils (manuels ou automatiques) et des decisions de produire, louer ou acheter les ressources. 
Cette technique permet a I’equipe d’evaluer les variables en termes de ressources, de cout et de duree afin de 
choisir une approche optimale pour accomplir le travail du projet. 

♦ Analyse de la reserve. L’analyse de la reserve est utilisee pour determiner le volume de la reserve pour imprevus 
et aleas necessaire au projet. Afin de prendre en compte les incertitudes de I’echeancier, des reserves pour aleas, 
que I'on appelle parfois reserves de I’echeancier, peuvent etre introduites dans les estimations de durees. II s’agit 
de la duree estimee incluse dans la reference de base de I'echeancier, qui est allouee aux risques identifies et 
acceptes. Les reserves pour aleas sont associees aux risques identifies et peuvent etre estimees pour tenir 
compte de la quantite des reprises inconnue. La reserve pour aleas peut etre un pourcentage de la duree des 
activites estimee ou un nombre de periodes de travail fixe. Les reserves pour aleas peuvent etre separees 
des activites individuelles et regroupees. Au fur et a mesure que des informations plus exactes sur le projet 
deviennent disponibles, les reserves pour aleas peuvent etre utilisees, reduites ou supprimees. Ces aleas doivent 
etre clairement identifies dans la documentation de I’echeancier. 

Par ailleurs, la valeur de la reserve pour imprevus de I’echeancier du projet peut egalement etre estimee. Les 
reserves pour imprevus sont un montant specifique dans le budget du projet retenu a des fins de maTtrise du 
management. En outre, elles sont reservees pour des travaux imprevus faisant partie du perimetre du projet. 
Les reserves pour imprevus permettent de gerer les risques non identifies susceptibles d’influer sur un projet. 
Elles ne font pas partie de la reference de base de I’echeancier, mais des exigences generates en matiere de 
duree du projet. En fonction des conditions contractuelles, I’utilisation des reserves pour imprevus peut exiger un 
changement de la reference de base de I’echeancier. 
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6.4.2.7 PRISE DE DECISION 

Elle est decrite a la section 5.2.2.4. Les techniques de prise de decision pouvant etre utilisees pour ce processus 
comprennent notamment le vote. Une variante de la methode de vote souvent utilisee dans les projets fondes sur une 
methode agile s'appelle «les cinq doigts de la main ». Dans cette technique, le chef de projet demande a I’equipe de 
montrer son niveau de soutien a regard d’une decision en levant un poing ferine (absence de soutien) ou un certain 
nombre de doigts (jusqu’a 5, indiquant alors un soutien total). Si un membre de I’equipe leve moins de trois doigts, il a 
la possibility de discuter de ses objections avec I’equipe. Le chef de projet poursuit le processus des«cinq doigts de la 
main»jusqu’a ce que I’equipe parvienne a un consensus (chaque membre leve au moins trois doigts) ou convienne de 
passer a la decision suivante. 

6.4.2.8 REUNIONS 

L’equipe projet peuttenir des reunions pour estimer la duree des activites. En cas d’utilisation d’une approche agile, il 
est necessaire de tenir des reunions de planification d'iteration ou des melees quotidiennes afin d’examiner les elements 
prioritaires de la liste des besoins en attente (backlog) (user stories) et de determiner les elements sur lesquels I’equipe 
s'engage atravailler lors de la prochaine iteration. L’equipe divise les scenarii d’utilisateur en taches de niveau inferieur, 
avec des estimations en heures, puis valide la faisabilite de ces estimations en fonction de la capacity de I'equipe sur la 
duree (iteration). Cette reunion se tient generalement le premier jour de I’iteration, Elle rassemble le responsable produit 
(product owner), I'equipe de la melee et le chef de projet. Le resultat de la reunion comprend une liste des besoins en 
attente pour les iterations, ainsi que les hypotheses, les preoccupations, les risques, les dependences, les decisions et 
les actions. 


6.4.3 ESTIMER LA DUREE DES ACTIVITES : DONNEES DE SORTIE 

6.4.3.1 ESTIMATIONS DE DUREES 

Les estimations de durees sont des evaluations quantitatives du nombre probable de periodes de temps qui seront 
necessaires a I’achevement d’une activity, d’une phase ou d’un projet. Ces estimations n’incluent aucun des retards 
decrits a la section 6.3.2.3. Les estimations de durees peuvent presenter certaines indications sur la plage de resultats 
possibles. Par exemple: 

♦ une plage de 2 semaines ± 2 jours indique une duree d’activite comprise entre un minimum de 8 jours et un 
maximum de 12 jours (sur la base d’une semaine de travail de 5 jours); 

♦ il existe 15 % de probability de depasser 3 semaines, ce qui indique une forte probability (85 %) que I’activite 
dure 3 semaines ou moins. 
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6.4.3.2 BASE DES ESTIMATIONS 


La quantite et le type de details supplementaires utilises dans I’estimation de durees dependent du domaine 
d’application. Quel que soit le niveau de detail, la documentation fournie doit permettre une comprehension claire et 
exhaustive de la fagon dont I'estimation de durees a ete obtenue. 

Les details a I’appui des estimations de durees peuvent comprendre: 

♦ la documentation des bases de I’estimation (c’est-a-dire sur la fagon dont elle a ete etablie); 

♦ la documentation de toutes les hypotheses formulees ; 

♦ la documentation de toutes les contraintes connues ; 

♦ I'indication des plages d'estimation possibles (par exemple, ±10 %) pour montrer qu’il est prevu que la duree de 
I’element se situe dans cette plage ; 

♦ I’indication du niveau de confiance de I’estimation finale ; 

♦ la documentation des risques individuels du projet ayant une influence sur cette estimation. 

6.4.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Attributs des activites. Ils sont decrits a la section 6.2.3.2. Les estimations de la duree d’une activite produites 
au cours de ce processus sont documentees dans les attributs des activites. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. II inclut les hypotheses emises lors de I’etablissement 
de I’estimation de la duree des activites, par exemple, les niveaux de competence et de disponibilite, ainsi qu’une 
base des estimations de durees. Les contraintes resultant de la methodologie de planification et de I’outil de 
planification sont egalement documentees. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience 
peut etre mis a jour de fagon a inclure les techniques qui se sont averees efficaces dans I’etablissement des 
estimations relatives aux efforts et aux durees. 


204 


Premiere partie - Guide 



6.5 ELABORER L’ECHEANCIER 

Elaborer I’echeancier est le processus qui consiste a analyser des sequences d’activites, des durees, des besoins en 
ressources et des contraintes de I’echeancier pour creer un modele d’echeancier a des fins d’execution et de maitrise 
du projet. L’interet principal de ce processus est qu’il genere un modele d’echeancier fixant des dates pour I’achevement 
des activites du projet. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques 
et les donnees de sortie de ce processus sont represents sur la figure 6-14. La figure 6-15 represente le diagramme 
de flux de donnees du processus. 


Elaborer l’echeancier 


Donnees d’entree V Outils et techniques H Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Base des estimations 

• Estimations de durees 

• Registre des retours 
d'experience 

• Liste des jalons 

• Diagrammes de reseau 
du projet 

• Affectations des membres 
de I'equipe projet 

• Calendriers des ressources 

• Besoins en ressources 

• Registre des risques 
.3 Accords 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v___y 


.1 Analyse du diagramme 
de reseau 

.2 Methode du chemin critique 
.3 Optimisation des ressources 
.4 Analyse des donnees 

• Analyse par scenario 

• Simulation 

.5 Avances et retards 
.6 Compression de I'echeancier 
.7 Systeme d’information 
de gestion du projet (Project 
Management Information 
System, PMIS) 
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Figure 6-14. Elaborer I’echeancier: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 6-15. Elaborer I’echeancier: diagramme de flux de donnees 
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L'elaboration d’un echeancier acceptable du projet est un processus iteratif. Le modele d’echeancier est utilise pour 
determiner, en fonction des meilleures informations disponibles, les dates de debut et de fin prevues des activites du 
projet, ainsi que les jalons. L'elaboration de l’echeancier peut necessiter la revue et la mise a jour des estimations de 
durees et de ressources, mais aussi des reserves de I’echeancier de fagon a elaborer un echeancier approuve du projet 
qui peut servir de reference de base pour le suivi de I’avancement du projet. Les principales etapes incluent la definition 
des jalons du projet, I'identification et le sequencement des activites ainsi que I’estimation des durees. Une fois les dates 
de debut et de fin des activites fixees, on demande generalement aux membres de I’equipe projet de passer en revue 
les activites qui leur ont ete affectees. Les membres de I’equipe projet confirment que les dates de debut et de fin ne 
presentent aucun conflit avec les calendriers des ressources ou les activites affectees pour d’autres projets ou taches 
et qu'elles sont done toujours valides. L'echeancier est ensuite analyse afin de determiner les conflits avec les liens 
logiques et de verifier si le nivellement des ressources est necessaire avant I'approbation de l'echeancier et la definition 
d’une reference de base. Les efforts de mise a jour et d’adaptation du modele d’echeancier du projet se poursuivent afin 
de maintenir un echeancier realiste tout au long de la duree du projet, comme decrit a la section 6.7. 

Pour plus d’informations specifiques a I’echeancier, voir le Practice Standard for Scheduling (en anglais seulement). 


6.5.1 ELABORER L’ECHEANCIER : DONNEES D’ENTREE 

6.5.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants : 

♦ Plan de gestion de l’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I’echeancier identifie la 
methode et I’outil de planification utilises pourcreer I’echeancier, mais aussi la fagon de le calculer. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. L’enonce du perimetre, le WBS et le 
dictionnaire du WBS detaillent les livrables du projet pris en compte lors de l'elaboration du modele d’echeancier. 

6.5.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Attributs des activites. Ils sont decrits a la section 6.2.3.2. Les attributs des activites fournissent les details qui 
servent a elaborer le modele d’echeancier. 

♦ Liste d’activites. Elle est decrite a la section 6.2.3.1. La liste d’activites identifie les activites qui seront incluses 
dans le modele d’echeancier. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Les hypotheses et les contraintes consignees dans 
le journal des hypotheses peuvent generer des risques de projet individuels susceptibles d’avoir un impact sur 
l’echeancier du projet. 
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♦ Base des estimations. Elle est decrite a la section 6.4.3.2. La quantite et le type de details supplemental 
utilises dans I’estimation de durees dependent du domaine d'application. Quel que soit le niveau de detail, la 
documentation fournie doit permettre une comprehension claire et exhaustive de la fagon dont I’estimation de 
durees a ete obtenue. 

♦ Estimations de durees. Elies sont decrites a la section 6.4.3.1. Les estimations de la duree des activites sont 
des evaluations quantitatives du nombre probable de periodes de travail qui seront necessaires a I'achevement 
des activites. Elies seront utilisees pour calculer I’echeancier. 

♦ Retours d’experience. Ils sont decrits a la section 4.4.3.1. Les retours d’experience du debut du projet concernant 
I’elaboration du modele d’echeancier peuvent etre appliques aux phases ulterieures afin d’ameliorer la validite 
du modele d’echeancier. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. La liste des jalons indique les dates prevues des jalons 
specifiques. 

♦ Diagrammes de reseau du projet. Ils sont decrits a la section 6.3.3.1. Les diagrammes de reseau du projet 
contiennent les liens logiques entre les activites predecesseurs et les activites successeurs qui seront utilisees 
pour calculer I’echeancier. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.1. Les affectations des 
membres de I’equipe projet specified quelles ressources sont affectees a chacune des activites. 

♦ Calendriers des ressources. Ils sont decrits a la section 9.2.1.2. Les calendriers des ressources contiennent 
des informations quant a la disponibilite des ressources durant le projet. 

♦ Besoins en ressources. Ils sont decrits a la section 9.2.3.1. Les besoins en ressources des activites permettent 
d'identifier les types et les quantites de ressources necessaires a chacune des activites utilisees pour creer le 
modele d’echeancier. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques fournit les details de tous les 
risques identifies et leurs caracteristiques qui auront un impact sur le modele d’echeancier. Les informations sur 
les risques lies a I’echeancier sont refletees dans les reserves de I’echeancier a I’aide de I’impact en termes de 
risque prevu ou moyen. 

6.5.1.3 ACCORDS 

Ils sont decrits a la section 12.2.3.2. En detaillant la fagon dont ils vont accomplir le travail du projet en vue de satisfaire 
aux engagements contractuels, les fournisseurs peuvent obtenir une donnee d’entree pour I’echeancier du projet. 
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6.5.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Elaborer 
I’echeancier, on peut citer: 

♦ les standards gouvernementaux ou industriels; 

♦ les canaux de communication. 

6.5.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Elaborer I’echeancier, on peut citer: 

♦ la methodologie de planification contenant les politiques regissant I’elaboration et la conservation du 
modele d’echeancier; 

♦ le ou les calendriers du projet. 

6.5.2 ELABORER L’ECHEANCIER : OUTILS ET TECHNIQUES 
6.5.2.1 ANALYSE DU DIAGRAMME DE RESEAU 

L’analyse du diagramme de reseau est la principale technique qui permet de creer le modele de I’echeancier du 
projet. Elle utilise plusieurs autres techniques, telles que la methode du chemin critique (decrite a la section 6.5.2.2), les 
techniques d’optimisation des ressources (decrites a la section 6.5.2.3) et les techniques de modelisation (decrites a la 
section 6.5.2.4). L’analyse complementaire inclut notamment: 

♦ revaluation de la necessity de regrouper les reserves d’echeancier afin de reduire toute probability d’erreur 
dans I’echeancier lorsque plusieurs chemins convergent en un moment unique ou lorsque plusieurs chemins 
divergent a partir du meme moment; 

♦ la verification du reseau afin de voir si le chemin critique presente des activites a haut risque ou de longues 
avances qui necessitent I’utilisation de reserves d’echeancier ou I’execution de reponses aux risques en vue de 
reduire le risque sur le chemin critique. 

L’analyse du diagramme de reseau est un processus iteratif qui est utilise jusqu'a I’elaboration d’un modele 
d'echeancier fiable. 
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6.5.2.2 METHODE DU CHEMIN CRITIQUE 


La methode du chemin critique est la methode utilisee pour estimer la duree minimum du projet et determiner le 
degre de flexibilite de I'echeancier sur les chemins de reseau logiques. La technique de I'analyse du diagramme de 
reseau calcule les dates de debut et de fin au plus tot ainsi que les dates de debut et de fin au plus tard de chacune 
des activites, sans tenir compte d’aucune limitation de ressource, en effectual une analyse du diagramme de reseau 
du projet, par calcul au plus tot et au plus tard, comme represente sur la figure 6-16. Dans cet exemple, le chemin le 
plus long comprend les activites A, C et D. C’est pourquoi la sequence A-C-D constitue le chemin critique. Le chemin 
critique est la sequence d’activites qui represente le chemin le plus long du projet et qui determine la duree la plus 
courte possible de ce projet. Le chemin le plus long montre la marge totale la plus faible, generalement nulle. Les dates 
de debut et de fin au plus tot et au plus tard qui en resultent ne constituent pas necessairement I'echeancier du projet. 
Elies indiquent plutot les intervalles de temps pendant lesquels chacune des activites peut etre executee, au vu des 
parametres du modele d’echeancier, a savoir les durees des activites, les liens logiques, les avances, les retards et les 
autres contraintes connues. La methode du chemin critique est utilisee pour calculer le ou les chemins critiques, la 
duree de la marge libre ou totale ou encore le degre de flexibilite de I’echeancier sur les chemins de reseau logiques 
du modele d’echeancier. 

Pour n’importe quel chemin du reseau, la marge totale ou la flexibilite de I'echeancier est mesuree par le temps dont 
une activite de I'echeancier peut etre retardee ou prolongee, par rapport a sa date de debut au plus tot, sans retarder la 
date de fin du projet ni transgresser une contrainte de I'echeancier. Un chemin critique est habituellement caracterise 
par le fait que la marge totale du chemin critique est nulle. Suivant le sequencement par la methode des antecedents, 
les chemins critiques peuvent avoir une marge totale positive, nulle ou negative, selon les contraintes appliquees. II 
existe une marge totale positive lorsque le calcul au plus tard est effectue a partir d’une contrainte d’echeancier se 
situant apres la date de fin au plus tot donnee par I’analyse du calcul au plus tot. Une marge totale negative resulte 
de la transgression d’une contrainte sur les dates au plus tard au niveau de la duree et de la logique. L’analyse de 
la marge negative est une technique qui permet de trouver des possibility de moyens acceleres pour remettre un 
echeancier retarde sur la bonne voie. Les reseaux d’echeancier peuvent comporter plusieurs chemins quasi critiques. 
Bon nombre de logiciels permettent a I’utilisateur de definir les parametres utilises pour determiner le ou les chemins 
critiques. L’integration d’ajustements des durees des activites (lorsqu’il est possible de prevoir plus de ressources ou 
un perimetre moins vaste), des liens logiques (lorsque les liens etaient optionnels au depart), des avances, des retards 
ou d’autres contraintes de I'echeancier permet d’obtenir des chemins de reseau a marge totale nulle ou positive. Une 
fois que la marge totale et la marge libre ont ete calculees, la marge libre correspond au temps pendant lequel une 
activite de I’echeancier peut etre reportee sans retarder la date de debut au plus tot de toute activite successeur ou sans 
transgresser une contrainte de I’echeancier. Par exemple, la marge libre de I'Activite B, a la figure 6-16, est de 5 jours. 
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Figure 6-16. Exemple de methode du chemin critique 


6.5.2.3 OPTIMISATION DES RESSOURCES 

L’optimisation des ressources est utilisee pour ajuster les dates de debut et de fin des activites de fagon a ce que 
I’utilisation des ressources prevues soit egale ou inferieure a la disponibilite des ressources. Parmi les exemples de 
techniques d’optimisation des ressources qui peuvent etre utilisees pour ajuster le modele d’echeancier en fonction de 
I’offre et de la demande de ressources, on peut citer les elements suivants : 

♦ Nivellement des ressources. Selon cette technique, les dates de debut et de fin sont ajustees en fonction des 
contraintes de ressources, dans le but d’assurer I’equilibre entre la demande des ressources et leur disponibilite. 
Le nivellement des ressources peut etre applique lorsque les ressources partagees, ou de necessity critique, ne 
sont disponibles qu’a certaines periodes ou en quantites limitees ou lorsqu'elles sont suraffectees, ce qui serait 
le cas d’une ressource attribute a deux ou a plusieurs activites pendant la meme periode de temps, comme le 
montre la figure 6-17, ou encore pour maintenir I’utilisation des ressources a un niveau constant. Le nivellement 
des ressources peut souvent entramer le changement du chemin critique initial. La marge disponible est utilisee 
pour niveler les ressources. Par consequent, le chemin critique tout au long de I’echeancier du projet peut changer. 

♦ Lissage des ressources. Cette technique permet d'ajuster les activites d’un modele d’echeancier de telle sorte 
que les besoins en ressources pour le projet ne depassent pas certaines limites de ressources predefines. Dans 
ce cas, et contrairement au nivellement des ressources, le chemin critique du projet ne change pas, et la date de 
fin du projet n’est pas necessairement retardee. En d'autres termes, les activites ne peuvent etre retardees que 
dans la limite de leur marge libre et de leur marge totale. II est possible que le lissage des ressources ne permette 
pas d’optimisertoutes les ressources. 
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Figure 6-17. Nivellement des ressources 
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6.5.2.4 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse par scenario. L’analyse par scenario est le processus qui consiste a evaluer des scenarii afin de predire 
leur effet, positif ou negatif, sur les objectifs du projet. Cette analyse etudie la question suivante: que se produirait- 
il si la situation representee par le scenario X survenait ? Une analyse du diagramme de reseau est effectuee 
en utilisant I'echeancier pour calculer les differents scenarii, tels qu’un retard dans la livraison d’un composant 
majeur, le prolongement de la duree d’etudes specifiques d'ingenierie ou I’introduction de facteurs externes, 
comme une greve ou un changement dans le processus de delivrance d’une autorisation. Le resultat de I'analyse 
par scenario permet d’evaluer la faisabilite de I'echeancier du projet dans diverses conditions, mais aussi de 
preparer des reserves d’echeancier et des plans de reponse pour surmonter I’impact de situations inattendues. 

♦ Simulation. La simulation permet de modeliser les effets combines des risques individuels du projet et des 
autres sources d’incertitude afin d’evaluer leur impact potentiel sur la realisation des objectifs du projet. La 
technique de simulation la plus frequemment utilisee est la methode de Monte Carlo (voir la section 11.4.2.5), 
dans laquelle les risques et les autres sources d'incertitude servent a calculer les eventuels resultats en termes 
d’echeancier pour le projet total. La simulation suppose de calculer les durees de plusieurs lots de travaux avec 
differents ensembles d’hypotheses d’activites, de contraintes, de risques, de points a traiter ou de scenarii en 
utilisant les distributions de probability et d’autres representations de I'incertitude (voir la section 11.4.2.4). La 
figure 6-18 montre une distribution de probabilite pour un projet avec la probabilite d’atteindre une certaine date 
cible (la date de fin du projet). Dans cet exemple, il existe une probabilite de 10 % que le projet s’acheve a la date 
cible du 13 mai ou avant, et une probabilite de 90 % qu’il s'acheve le 28 mai. 
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Figure 6-18. Exemple de distribution des probability liees a un jalon cible 


Pour de plus amples informations sur I’utilisation de la simulation de Monte-Carlo avec les modeles d’echeancier, 
voir le Practice Standard for Scheduling (en anglais seulement). 

6.5.2.5 AVANCES ET RETARDS 

Ms sont decrits a la section 6.3.2.3. Les avances et les retards sont des ameliorations apportees lors de I’analyse de 
reseau, de fagon a obtenir un echeancier viable en ajustant la date de debut des activites successeurs. Les avances 
sont utilisees dans des cas limites pour avancer le debut d’une activite successeur par rapport a I'activite predecesseur, 
tandis que les retards sont utilises dans des cas limites la oil les processus exigent de laisser s'ecouler une periode de 
temps definie entre les activites predecesseurs et les activites successeurs sans impact sur le travail ou les ressources. 
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6.5.2.6 COMPRESSION DE L’ECHEANCIER 

Les techniques de compression de I'echeancier sont utilisees pour raccourcir ou accelerer la duree de I'echeancier 
sans reduire le perimetre du projet, afin de respecter les contraintes de I'echeancier et les dates imposees, ou de 
satisfaire d'autres objectifs de I'echeancier. Une technique utile est I'analyse de la marge negative. Le chemin critique 
presente la marge la plus reduite. En raison du non-respect d’une contrainte ou d’une date imposee, la marge totale 
peut devenir negative. Les techniques de compression de I’echeancier sont comparees a la figure 6-19 et comprennent 
les elements suivants: 

♦ Compression des delais. Technique utilisee pour reduire la duree de I'echeancier pour un cout minimum, en 
ajoutant des ressources. Parmi les exemples de compression des delais sur les activites du chemin critique, 
on peut citer I’approbation d’heures supplementaires, I'apport de ressources supplementaires ou le paiement 
d’un supplement pour accelerer une livraison. La compression des delais ne donne de resultats qu’avec des 
activites du chemin critique pour lesquelles des ressources supplementaires permettront de reduire la duree. La 
compression des delais n’offre pas toujours de solution viable et peut entraTner une augmentation des risques 
et des couts. 

♦ Mise en parallele. Cette technique de compression de I'echeancier prevoit I’execution en parallele, tout au 
moins sur une partie de leur duree, des activites, ou des phases normalement executees en sequence. On peut 
citer, a titre d’exemple, la construction des fondations d’un batiment alors que les plans d’architecte ne sont 
pas encore termines. La mise en parallele peut entraTner une reprise du travail et un accroissement des risques. 
Cette technique de mise en parallele ne donne de resultats que si les activites peuvent se chevaucher afin de 
raccourcir la duree du projet sur le chemin critique. L'utilisation d’avances en cas d’acceleration de I'echeancier 
intensifie generalement les efforts de coordination entre les activites concernees et augmente le risque en termes 
de qualite. La mise en parallele peut egalement augmenter les couts du projet. 
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Figure 6-19. Comparaison de la compression de I’echeancier 
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6.5.2.7 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d'information de management du projet incluent les logiciels de 
planification qui facilitent le processus d’elaboration d’un modele d’echeancier en generant des dates de debut et de fin 
sur la base des donnees d’entree des activites, des diagrammes de reseau, des ressources et des durees des activites. 


6.5.2.8 PLANIFICATION DES RELEASES AGILE 

La planification de release agile offre un calendrier recapitulate de haut niveau de I’echeancier des releases 
(generalement 3 a 6 mois) sur la base de la feuille de route et de la vision du produit pour son evolution. La 
planification de releases agile determine egalement le nombre d’iterations ou de melees dans le cadre de la release. 
Elle permet aussi au responsable produit de decider des developpements necessaires et du temps qu’il faudra pour 
obtenir un produit commercialisable en fonction des objectifs commerciaux, des dependances et des obstacles. 

Comme les caracteristiques offrent une valeur au client, le calendrier permet de mieux comprendre I’echeancier 
du projet, car il definit la caracteristique qui sera disponible a la fin de chaque iteration, ce qui correspond exactement 
a la qualite d'information recherchee par le client. 

La figure 6-20 montre le lien entre la vision et la feuille de route du produit, la planification de release et la 
planification des iterations. 
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Figure 6-20. Relation entre la vision du produit ainsi que, la planification de releases et des iterations 


216 


Premiere partie - Guide 



































































6.5.3 ELABORER L’ECHEANCIER : DONNEES DE SORTIE 


6.5.3.1 REFERENCE DE BASE DE L’ECHEANCIER 

Une reference de base de I'echeancier est la version approuvee d’un modele d’echeancier qui ne peut etre modifiee 
que par des procedures formelles de maTtrise des changements et qui est utilisee comme base de comparaison avec 
les resultats reels. Elle est acceptee et approuvee par les parties prenantes appropriees, comme reference de base de 
I’echeancier comprenant les dates de reference de debut et de fin. Au cours de la maTtrise, les dates de reference de 
base sont comparees aux dates de debut et de fin reelles pour determiner si des ecarts sont survenus. La reference de 
base de I’echeancier est un composant du plan de management du projet. 

6.5.3.2 ECHEANCIER DU PROJET 

L’echeancier du projet est une donnee de sortie d’un modele d’echeancier qui presente les activites liees avec des 
dates planifiees, des durees, des jalons et des ressources. II comporte, au minimum, pour chaque activite des dates 
prevues de debut et de fin. Si la planification des ressources est effectuee dans une phase initiale, I’echeancier du 
projet demeure sous une forme preliminaire jusqu'a la confirmation des allocations en ressources et I'etablissement 
des dates planifiees de debut et de fin. Habituellement, ce processus intervient au plus tard a I’achevement du plan de 
management du projet (voir la section 4.2.3.1). Un modele d’echeancier cible du projet peut egalement etre etabli avec 
des dates cibles de debut et de fin definies pour chaque activite. L’echeancier du projet peut se presenter sous une 
forme resumee, que I'on appelle parfois echeancier directeur ou echeancier a jalons, ou sous une forme detaillee. Bien 
qu’un modele d’echeancier du projet puisse etre presente sous forme de tableau, il est le plus souvent presente sous 
forme graphique dans un ou plusieurs des formats suivants : 

♦ Graphique a barres. Egalement connus sous le nom de diagrammes de Gantt, les graphiques a barres 
represented des donnees de I’echeancier dans lesquelles les activites sont presentees sur I'axe des ordonnees, 
les dates sont indiquees sur I’axe des abscisses et les durees des activites sont representees sous forme de 
barres horizontales placees en fonction des dates de debut et de fin correspondantes. Les graphiques a barres 
sont relativementfaciles a lire et sontfrequemment utilises. En fonction du public, la marge peut etre representee 
ou non. Pour les communications de maTtrise ou de gestion, on utilise la notion de consolidation d’activites, plus 
large et plus comprehensible, entre des jalons ou pour couvrir plusieurs lots de travaux interdependants, qui est 
presentee dans les rapports des graphiques a barres. La figure 6-21 il lustre une partie resumee de I’echeancier, 
presentee sous la forme d’un WBS. 
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♦ Diagrammes a jalons. Ces diagrammes sont similaires aux graphiques a barres, mais ils identifient uniquement 
les dates planifiees de debut ou d’achevement des livrables majeurs et les interfaces externes cles. La partie de 
I’echeancier a jalons de la figure 6-21 en est une illustration. 

♦ Diagrammes de reseau du projet. Ces diagrammes sont generalement presentes sous forme de diagrammes 
d’activites sur noeuds montrant les activites et les relations sans echelle de temps, parfois appeles diagrammes 
de logique pure, comme sur la figure 6-11, ou sous forme de diagramme de reseau d’echeancier a echelle 
de temps, quelquefois appeles graphique a barres logique, comme indique pour I'echeancier detaille de 
la figure 6-21. En regie generate, ces diagrammes, comportant des informations sur les dates des activites, 
montrent a la fois la logique du reseau et les activites de I’echeancier situees sur le chemin critique du projet. 
Cet exemple montre egalement comment chaque lot de travaux est planifie en une serie d’activites connexes. 
Une autre presentation du diagramme de reseau du projet est un diagramme logique a echelle de temps. Ces 
diagrammes comprennent une echelle de temps et des barres qui represented la duree des activites avec la 
relation logique. Ils sont optimises pour illustrer la relation entre les activites lorsque plusieurs d’entre elles 
peuvent apparaTtre en sequence sur la meme ligne du diagramme. 

La figure 6-21 montre des presentations d’echeancier pour un exemple de projet en cours d’execution, sur lequel 
le travail en cours est indique jusqu'a la date courante ou d’enregistrement de I'etat du projet. Pour un modele simple 
d’echeancier du projet, la figure 6-21 illustre les presentations de I'echeancier sous la forme d’un echeancier a jalons 
par un graphique a jalons, d’un resume de I’echeancier par un graphique a barres et d’un echeancier detaille par 
un graphique a barres lie a I’echeancier du projet. La figure 6-21 illustre egalement les liens entre les trois niveaux 
differents de presentation de I’echeancier du projet. 
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Figure 6-21. Exemples de presentations d’echeancier du projet 
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6.5.3.3 DONNEES DE L’ECHEANCIER 


Les donnees de I'echeancier pour le modele d’echeancier du projet sont I’ensemble des informations utilisees pour 
decrire et maTtriser I’echeancier. Les donnees de I'echeancier comprennent au moins les jalons de I'echeancier, les 
activites de I'echeancier, les attributs des activites et la documentation de toutes les hypotheses et de toutes les 
contraintes identifies. La quantite de donnees supplementaires varie en fonction du champ d’application. Parmi les 
informations frequemment fournies a titre de precisions, on peut citer: 

♦ les besoins en ressources par intervalle de temps, souvent presentes sous forme d’un histogramme des 
ressources; 

♦ des variantes d'echeanciers, tels que le meilleur et le pire des cas, I’echeancier avec ou sans nivellement des 
ressources et I'echeancier avec ou sans dates imposees ; 

♦ les reserves de I'echeancier utilisees. 

Les donnees de I'echeancier peuvent aussi comprendre des elements, tels que les histogrammes de ressources, les 
previsions de tresorerie, les echeanciers de commande et de livraison ou toute autre information pertinente. 

6.5.3.4 CALENDRIERS DU PROJET 

Un calendrier du projet identifie les jours ouvrables et les horaires disponibles pour les activites planifiees. II fait la 
distinction entre les intervalles de temps en jours ou en portions de journees disponibles pour executer les activites 
planifiees et les intervalles de temps qui ne sont pas disponibles. Un modele d’echeancier peut necessiter plusieurs 
calendriers du projet pour octroyer differentes periodes de travail a certaines activites dans le calcul de I’echeancier du 
projet. Les calendriers du projet peuvent etre mis a jour. 

6.5.3.5 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Les changements apportes au perimetre ou a I'echeancier du projet peuvent 
generer des demandes de changement relatives a la reference de base du perimetre ou a d’autres elements du plan de 
management du projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les 
changements (voir la section 4.6). Les actions preventives peuvent comprendre les changements recommandes pour 
eliminer ou reduire la probabilite d’ecarts de delais negatifs. 
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6.5.3.6 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I'echeancier peut etre 
mis a jour pour refleter un changement dans la fagon dont I’echeancier a ete elabore et sera gere. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference de 
base des couts sont integres en fonction de I’approbation des changements du perimetre, des ressources ou des 
estimations des couts. Dans certains cas, lorsque les ecarts de cout sont tres importants, une mise a jour de la 
reference de base des couts est necessaire, de fagon a disposer d’une base realiste de mesure de performance. 

6.5.3.7 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Attributs des activites. Ms sont decrits a la section 6.2.3.2. Les attributs des activites sont mis a jour de fagon 
a inclure tous les besoins en ressources actualises et toute autre mise a jour issue de I’execution du processus 
Elaborer I’echeancier. 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses peut etre mis a jour afin 
d’inclure les changements apportes aux hypotheses en termes de duree, d’utilisation des ressources et de 
sequencement ou toute autre information revelee dans le cadre de I’elaboration du modele d’echeancier. 

♦ Estimations de durees. Elies sont decrites a la section 6.4.3.1. Le nombre et la disponibilite des ressources, 
ainsi que les dependances entre les activites peuvent entrainer un changement dans les estimations de durees. 
Si I’analyse du nivellement des ressources modifie les besoins en ressources, les estimations de durees sont 
egalement susceptibles de necessiter une mise a jour. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour de fagon a inclure les techniques qui se sont averees efficaces dans I’elaboration du modele 
d’echeancier. 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Le nivellement des ressources peut avoir un effet 
significatif sur les estimations preliminaires des types et des quantites de ressources necessaires. Si I'analyse 
du nivellement des ressources modifie les besoins en ressources du projet, ces besoins doivent etre mis a jour. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques peut etre mis a jour pour refleter 
les opportunity ou les menaces que font apparaTtre les hypotheses de la planification. 
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6.6 MAITRISER L’ECHEANCIER 


MaTtriser I’echeancier est le processus qui consiste a maitriser I’etat du projet, dans le but de mettre a jour I’echeancier 
du projet et de gerer les changements affectant la reference de base de I’echeancier. L’interet principal de ce processus 
est qu’il permet de conserver la reference de base de I’echeancier tout au long du projet. Ce processus est execute 
tout au long du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont 
represents sur la figure 6-22. La figure 6-23 represente le diagramme de flux de donnees du processus. 


Maitriser l’echeancier 


Donnees d’entree ■ Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
de I'echeancier 

• Reference de base 
du perimetre 

• Reference de base 
de la performance 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Calendriers du projet 

• Echeancier du projet 

• Calendriers des ressources 

• Donnees de I'echeancier 

.3 Donnees de performance 

d'execution 

.4 Actifs organisationnels 
V___ 


.1 Analyse des donnees 

• Analyse de la valeur acquise 

• Diagramme du travail 
restant (« burndown ») sur 
les iterations 

• Revues de performance 

• Analyse de la tendance 

• Analyse des ecarts 

• Analyse par scenario 

.2 Methode du chemin critique 
.3 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.4 Optimisation des ressources 
.6 Avances et retards 
.7 Compression de I'echeancier 
V _ 


.1 Information sur 

la performance d'execution 
.2 Previsions de I’echeancier 
.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 

• Plan de gestion 
de I'echeancier 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

• Reference de base 
de la performance 

.5 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Base des estimations 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Calendriers des ressources 

• Registre des risques 

• Donnees de I'echeancier 

\ _ / 


Figure 6-22. Maitriser I’echeancier: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion de I’echeancier 

• Reference de base de I’echeancier 

• Reference de base du perimetre 

• Reference de base de la performance 


Documents 
du projet 


Documents du projet 

• Registre des retours d’experience 

• Calendriers du projet 

• £cheancier du projet 

• Calendriers des ressources 

• Donnees de I’echeancier 


4.3 

Diriger 

et gerer le travail 
du projet 

Donnees de performance d'execution 


Entreprise/ 

Organisation 

Actifs organisationnels 


Informations sur la performance 
d'execution 


4.5 

Maitriser 
le travail 
du projet 


Demandes de changement 


4.6 

Effectuer 

la gestion integree 
des changements 



6.6 



Plan 


Maitriser 


w. .► 

de management 


I'echeancier 


; Misesajourdu plan 

I de management du projet 
l • Plan de gestion 

du projet 


de I’echeancier 
Reference de base de I'echeancier 
Reference de base des couts 
Reference de base de la performance 


Previsions 
de I’echeancier 


Documents 
du projet 


Misesajour 

des documents du projet 

• Journal des hypotheses 

• Base des estimations 

• Registre des retours d’experience 

• Echeancier du projet 

• Calendriers des ressources 

• Registre des risques 

• Donnees de I’echeancier 


Figure 6-23. Maitriser I’echeancier: diagramme de flux de donnees 


La mise a jour du modele d’echeancier exige de connaTtre la performance reelle a ce jour. Tout changement apporte 
a la reference de base de I’echeancier ne peut etre approuve que par le processus Maitriser les changements (voir la 
section 4.6). La maTtrise de I'echeancier, en tant que composante du processus Maitriser les changements, porte sur: 

♦ la determination de I’etat actuel de I’echeancier du projet; 

♦ I’influence des facteurs qui provoquent des changements dans I’echeancier; 

♦ le reexamen des reserves necessaires de I'echeancier; 

♦ la determination d’un quelconque changement de I’echeancier du projet; 

♦ la gestion des changements effectifs au fur et a mesure qu'ils se realisent. 
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En cas d'utilisation d’une approche agile, la maTtrise de I'echeancier porte sur: 

♦ la determination de I'etat actuel de I’echeancier du projet en comparant le volume total de travail fourni et 
accepte par rapport aux estimations du travail acheve pour le cycle ecoule; 

♦ la conduite de revues retrospectives (des revues planifiees pour enregistrer les retours d’experience) pour 
apporter des corrections aux processus, et les ameliorer s’il y a lieu ; 

♦ une nouvelle hierarchisation de la partie restante de la liste des besoins en attente (« backlog»); 

♦ la determination du rythme auquel les livrables sont produits, valides, et acceptes (velocite) dans un intervalle 
donne par iteration (duree de cycle de travail convenue, typiquement deux semaines ou un mois); 

♦ la constatation que I’echeancier du projet a ete modifie; 

♦ la gestion des changements effectifs au fur et a mesure qu’ils se realisent. 

Lorsque le travail est sous-traite, les mises a jour regulieres de I’etat des jalons aupres des sous-traitants et des 
fournisseurs sont un moyen de s’assurer du bon avancement du travail et de garantir la maTtrise de I’echeancier. Des 
revues d’etat et des revues structures planifiees doivent etre effectuees afin de s’assurer que les rapports du sous- 
traitant sont exacts et complets. 


6.6.1 MAITRISER L’ECHEANCIER : DONNEES D’ENTREE 

6.6.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. La gestion de I’echeancier decrit la frequence a 
laquelle I’echeancier sera mis a jour, la fagon dont la reserve sera utilisee et comment I’echeancier sera maTtrise. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. La reference de base de I’echeancier 
est comparee aux resultats reels de fagon a determiner si un changement, une action corrective ou une action 
preventive s’avere necessaire. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Le WBS, les livrables, les contraintes et 
les hypotheses du projet, documents dans la reference de base du perimetre, sont explicitement considers lors 
de la maTtrise de la reference de base de I'echeancier. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Dans le cadre de I’analyse de 
la valeur acquise, la reference de base de la performance est comparee a I’etat reel afin de determiner si un 
changement, une action corrective ou preventive s’avere necessaire. 
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6.6.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer la martrise de l’echeancier. 

♦ Calendriers du projet. Ils sont decrits a la section 6.5.3.4. Un modele d’echeancier peut exiger plusieurs 
calendriers du projet pour octroyer differentes periodes de travail a certaines activites dans le calcul des 
previsions de I’echeancier. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet fait reference a la version la plus 
recente avec des notes indiquant les mises a jour, les activites achevees et celles ayant debute a la date indiquee. 

♦ Calendriers des ressources. Ils sont decrits a la section 9.2.1.2. Les calendriers des ressources indiquent la 
disponibilite de I'equipe et des ressources physiques. 

♦ Donnees de l’echeancier. Elies sont decrites a la section 6.5.3.3. Les donnees de l’echeancier seront passees 
en revue et mises a jour par le processus MaTtriser I’echeancier. 

6.6.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d'execution comprennent des informations sur 
I’etat du projet, telles que les activites qui ont debute, leur avancement (par exemple, la duree reelle, la duree restante 
ou le pourcentage d’avancement physique) et les activites terminees. 

6.6.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser I’echeancier, on peut citer: 

♦ les politiques, les procedures et les instructions existantes, formelles et informelles, relatives a la maitrise de 
l'echeancier; 

♦ les outils de martrise de l'echeancier; 

♦ les methodes de maitrise et de communication a utiliser. 
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6.6.2 MAITRISER L’ECHEANCIER : OUTILS ET TECHNIQUES 


6.6.2.1 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse de la valeur acquise (EVM). Elle est decrite a la section 7.4.2.2. Les mesures de performance de 
I’echeancier, telles que les ecarts de delais et I’indice de performance des delais permettent d’evaluer I’importance 
de I’ecart par rapport a la reference de base initiate de I’echeancier. 

♦ Diagramme du travail restant (« burndown ») sur les iterations. Ce diagramme suit le travail qu’il reste a 
accomplir dans la liste des besoins (backlog) en attente des iterations. II est utilise dans I'analyse des ecarts 
eu egard a un temps de travail restant ideal base sur le travail engage dans le cadre de la planification des 
iterations (voir la section 6.4.2.8). Une ligne de tendance previsionnelle peut etre utilisee afin de predire I'ecart 
probable a la fin de I’iteration et de prendre les mesures appropriees au cours de celle-ci. Une ligne diagonale 
representant le temps de travail restant ideal et le travail restant reel quotidien est ensuite tracee. Puis, une 
ligne de tendance est calculee afin de prevoir I’achevement en fonction du travail restant. La figure 6-24 est un 
exemple de diagramme du travail restant sur les iterations. 



Figure 6-24. Diagramme du travail restant (<< burndown ») sur les iterations 
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♦ Revues de performance. Les revues de performance permettent de mesurer, de comparer et d’analyser la 
performance de I'echeancier dont, en particulier, les dates de debut et de fin reelles, le pourcentage d’avancement 
et la duree restante pour les travaux en cours, par rapport a la reference de base de I’echeancier. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5.2.2. L’analyse de la tendance consiste a examiner 
les performances du projet dans le temps pour determiner si elles s’ameliorent ou si elles se degradent. Les 
techniques d’analyse graphique sont precieuses, car elles permettent de comprendre la performance a une date 
donnee et de pouvoir la comparer aux objectifs de performance a venir, sous la forme de dates d'achevement. 

♦ Analyse des ecarts. L’analyse des ecarts examine les ecarts entre les dates de fin et de debut prevues et 
reelles, les durees prevues et reelles, mais aussi les ecarts de marge. L’analyse des ecarts consiste, entre 
autres, a determiner la cause et le degre d’ecart par rapport a la reference de base de I’echeancier (voir la 
section 6.5.3.1), a estimer les implications de ces ecarts dans I’achevement des travaux futurs et a decider si une 
action corrective ou preventive s'avere necessaire. Par exemple, un retard important sur une activite situee en 
dehors du chemin critique peut n’avoir qu’un faible impact sur I'ensemble de I’echeancier du projet, alors qu’un 
retard beaucoup moins important sur une activite critique ou quasi critique peut necessiter une action immediate. 

♦ Analyse par scenario. Elle est decrite a la section 6.5.2.4. L’analyse par scenario est utilisee pour evaluer 
les differents scenarii dictes par les donnees de sortie des processus de gestion des risques du projet, en vue 
d’aligner le modele d’echeancier sur le plan de management du projet et la reference de base approuvee. 

6.6.2.2 METHODE DU CHEMIN CRITIQUE 

Elle est decrite a la section 6.5.2.2. Comparer I'avancement sur le chemin critique peut contribuer a determiner I’etat 
de I’echeancier. Les ecarts intervenant sur le chemin critique auront un impact direct sur la date de fin du projet. Evaluer 
I’avancement des activites sur les chemins presque critiques peut permettre d'identifier un risque relatif a I’echeancier. 

6.6.2.3 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PROJECT MANAGEMENT INFORMATION 
SYSTEM, PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d’information de management du projet incluent les logiciels de 
planification permettant de suivre et de comparer les dates prevues aux dates reelles, de faire un etat des ecarts et 
de I'avancement par rapport a la reference de base de I'echeancier, mais aussi de prevoir les effets des changements 
apportes au modele d’echeancier du projet. 

6.6.2.4 OPTIMISATION DES RESSOURCES 

Elle est decrite a la section 6.5.2.3. Les techniques d’optimisation des ressources impliquent la planification des 
activites et des ressources requises par ces activites tout en tenant compte a la fois de la disponibilite des ressources 
et des delais du projet. 
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6.6.2.5 AVANCES ET RETARDS 


L’ajustement des avances et des retards est applique au cours de I'analyse du reseau, afin de trouver des moyens 
de realigner avec le plan les activites de projet qui sont en retard. Dans le cas d’un projet de construction d’un nouvel 
immeuble de bureaux, par exemple, I’amenagement du paysage peut etre ajuste pour demarrer avant que les travaux 
d’exterieur de I’immeuble ne soient acheves, en augmentant I’avance dans le lien de dependance. Ou encore, I’equipe 
de redaction technique peut ajuster [’initialisation de I’edition de I’ebauche d’un gros document immediatement apres 
la redaction du document en eliminant ou en diminuant le retard. 

6.6.2.6 COMPRESSION DE L’ECHEANCIER 

Les techniques de compression de I’echeancier (voir la section 6.5.2.6) sont utilisees pour trouver des moyens de 
realigner des activites de projet, qui sont en retard, par une mise en parallele rapide ou la compression des delais pour 
le travail restant. 


6.6.3 MAITRISER L’ECHEANCIER : DONNEES DE SORTIE 

6.6.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d’execution comporte des donnees relatives 
aux travaux du projet par rapport a la reference de base de I’echeancier. Les ecarts relatifs aux dates de debut et de fin 
ainsi qu'aux durees peuvent etre calcules au niveau d’un lot de travaux et d’un centre de consolidation. Pour les projets 
qui utilisent I’analyse de la valeur acquise, les ecarts de delai et I’indice de performance des delais sont documents et 
inclus dans les rapports sur la performance d’execution (voir la section 4.5.3.1). 

6.6.3.2 PREVISIONS DE L’ECHEANCIER 

Les previsions de I'echeancier sont des estimations ou des pronostics de situations et d'evenements a venir dans le 
deroulement du projet, etablis a partir des informations et des connaissances disponibles au moment de la prevision. 
Les previsions sont revisees et publiees a nouveau sur la base de I'information sur la performance d’execution fournie 
au fur et a mesure de I’execution du projet. Les informations reposent sur la performance passee du projet et la 
performance future attendue en fonction des actions correctives ou preventives. Elies peuvent inclure les indicateurs de 
performance de la valeur acquise (EVM), ainsi que les informations sur la reserve de I’echeancier susceptibles d'avoir 
un impact ulterieur sur le projet. 
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6.6.3.3 DEMANDES DE CHANGEMENT 


Elies sont decrites a la section 4.3.3.4. L’analyse de I'ecart de delais, ainsi que les revues des rapports d’avancement, 
les resultats des mesures de performance et les changements apportes au perimetre ou a I’echeancier du projet 
peuvent entrainer I’etablissement de demandes de changement de la reference de base de I’echeancier, du perimetre 
ou d’autres composants du plan de management du projet. Les demandes de changement sont passees en revue et 
traitees par le processus MaTtriser les changements (voir la section 4.6). Les actions preventives peuvent comprendre 
les changements recommandes pour eliminer ou reduire la probability d’ecarts de delais negatifs. 

6.6.3.4 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I’echeancier peut etre 
mis a jour pour refleter un changement dans la fagon dont I'echeancier est gere. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. Les changements apportes a la 
reference de base de I'echeancier sont incorpores a la suite de I'approbation des demandes de changement 
relatives aux changements du perimetre du projet, aux ressources des activites ou aux estimations de la duree 
des activites. La reference de base de I’echeancier peut etre mise a jour dans le but de refleter les changements 
resultant des techniques de compression de I'echeancier ou des problemes de performance. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference 
de base des couts sont integres en fonction de I'approbation des changements du perimetre, des ressources ou 
des estimations des couts. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Les changements apportes a la 
reference de base de la performance sont incorpores a la suite de I’approbation des changements concernant le 
perimetre, la performance des delais ou les estimations de couts. Dans certains cas, les ecarts de performance 
peuvent etre si importants qu’une demande de changement est presentee pour mettre a jour la reference de 
base de la performance, de fagon a disposer d’une base realiste de mesure de la performance. 
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6.6.3.5 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. L'execution de I’echeancier peut impliquer la necessity 
de revoir les hypotheses concernant le sequencement des activites, les durees et la productivity 

♦ Base des estimations. Elle est decrite a la section 6.4.3.2. La performance des delais peut impliquer la necessity 
de reviser la methode d’elaboration des estimations de durees. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour pour inclure les techniques qui se sont averees efficaces pour conserver I’echeancier, les causes 
des ecarts et les actions correctives utilisees pour combler les ecarts de delais. 

♦ Echeancier du projet. Un echeancier du projet mis a jour (voir la section 6.5.3.2) sera genere a partir du modele 
d’echeancier renseigne avec des donnees mises a jour, dans le but de refleter les changements de I’echeancier 
et de gerer le projet. 

♦ Calendriers des ressources. Ils sont decrits a la section 9.2.1.2. Les calendriers des ressources sont mis a jour 
afin de refleter les changements dans leur utilisation en consequence de I'optimisation des ressources, de la 
compression de I’echeancier et des actions preventives ou correctives. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques et les plans de reponse aux 
risques qu’il contient peuvent egalement etre mis a jour sur la base des risques susceptibles de survenir comme 
effet des techniques de compression de I'echeancier. 

♦ Donnees de I’echeancier. Elies sont decrites a la section 6.5.3.3. De nouveaux diagrammes de reseau du projet 
peuvent etre developpes dans le but de presenter les durees restantes approuvees et les changements approuves 
apportes a I’echeancier. Dans certains cas, les retards dans I’echeancier du projet peuvent etre suffisamment 
graves pour necessiter I’etablissement d’un nouvel echeancier cible, avec de nouvelles dates de debut et de 
fin prevues, apportant des donnees realistes pour diriger le travail, mais aussi pour mesurer la performance 
et I'avancement. 
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GESTION DES COUTS DU PROJET 

La gestion des couts du projet comprend les processus relatifs a la planification, a I’estimation, a I’etablissement du 
budget, au financement, au provisionnement, a la gestion et a la maTtrise des couts, afin que le projet soit acheve dans 
les limites du budget approuve. Les processus de gestion des couts du projet sont les suivants : 

7.1 Planifier la gestion des couts —Ce processus consiste a definir la maniere dont les couts du projet seront 
estimes, budgetes, geres et maitrises. 

7.2 Estimer les couts —Ce processus consiste a evaluer le cout des ressources monetaires necessaires a 
I’accomplissement des travaux du projet. 

7.3 Determiner le budget —Ce processus consiste a consolider les couts estimes de chacune des activites ou de 
chacun des lots de travaux afin d’etablir une reference de base des couts approuvee. 

7.4 MaTtriser les couts —Ce processus consiste a suivre I’etat du projet afin de mettre a jour les couts du projet et 
de gerer les changements de la reference de base des couts. 

La figure 7-1 presente une vue d’ensemble des processus de gestion des couts du projet. Les processus de gestion 
des couts du projet sont presentes comme des processus distincts aux interfaces clairement definies; cependant, dans 
la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre completement detaillees 
dans le Guide PMBOK®. Ces processus interagissent les uns avec les autres et avec les processus d’autres domaines 
de connaissance. 

Dans certains projets, particulierement ceux au perimetre plus petit, I'estimation des couts et I'etablissement du budget 
sont si etroitement liees qu’elles sont considerees comme un processus unique, pouvant etre effectue par une seule 
personne et en un temps relativement court. Ces processus sont presentes ici comme des processus distincts, car les 
outils et techniques utilises sont differents pour chacun d’eux. Lors des premieres etapes du projet, la capacite d'influencer 
le cout est plus grande. De ce fait, il est essentiel de definir au plus tot le perimetre du projet (voir la section 5.3). 
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Vue d’ensemble de la gestion 
des couts du projet 


7.1 Planifier la gestion 
des couts 


.1 Donnees d'entree 
.1 Charte du projet 
.2 Plan de management du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Reunions 

.3 Donnees de sortie 

.1 Plan de gestion des couts 

V_I_/ 


7.2 Estimer les couts 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Estimation paranalogie 
.3 Estimation parametrique 
.4 Estimation ascendante 
.5 Estimation a trois points 
.6 Analyse des donnees 
.7 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.8 Prise de decision 

3 Donnees de sortie 
.1 Estimations de couts 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

V___/ 


7.3 Determiner le budget 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Documents business 
.4 Accords 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Consolidation des couts 
.3 Analyse des donnees 
.4 Revue des donnees 
historiques 

.5 Reconciliation des limites 
de financement 
.6 Financement 
.3 Donnees de sortie 

.1 Reference de base des couts 
.2 Besoin en financement 
du pro jet 

.3 Mises a jour des documents 
du projet 

v___/ 


7.4 Vue d’ensemble 
de la gestion 
des couts du projet 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Besoins de financement 
du projet 

.4 Donnees de performance 
d'execution 

.5 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Indice de performance 
a terminaison du projet 
.4 Systeme d'information 
de gestion du projet 

.3 Donnees de sortie 
.1 Information sur 

la performance d'execution 
.2 Previsions de couts 
.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du projet 

V___/ 


Figure 7-1. Vue d’ensemble de la gestion des couts du projet 
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PRINCIPAUX CONCEPTS DE LA GESTION DES COUTS DU PROJET 

La gestion des couts du projet porte principalement sur le cout des ressources necessaires a I’achevement des 
activites du projet. L’effet des decisions du projet sur les couts recurrents ulterieurs d’utilisation, d’entretien et de 
support du produit, du service ou du resultat du projet doit egalement etre pris en compte. Par exemple, une limitation 
du nombre de revues de conception peut reduire le cout du projet mais egalement augmenter les couts d’exploitation 
du produit. 

Un autre aspect de la gestion des couts consiste a reconnartre que les differentes parties prenantes evaluent 
les couts du projet de differentes fagons a differents moments. Par exemple, le cout d’un element acquis peut etre 
mesure lorsque la decision d’obtention est prise ou engagee, la commande lancee, I'element livre ou bien le cout reel 
impute ou enregistre pour les besoins de la comptabilite du projet. Dans de nombreuses organisations, la prevision et 
I'analyse de la performance financier attendue du produit du projet sont faits en dehors du projet. Dans d’autres, un 
projet d’investissement industriel par exemple, ce travail peut faire partie de la gestion des couts du projet. Lorsque 
ces previsions et ces analyses font partie du projet, la gestion des couts du projet peut faire appel a des processus 
supplementaires et de nombreuses techniques de gestion, tels que le taux et le temps de retour sur investissement ou 
la valeur actualisee des flux de tresorerie et I’analyse des delais de recuperation des investissements. 

TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES COUTS DU PROJET 

Dans la pratique de la gestion des couts du projet, les tendances etendent la gestion de la valeur acquise (Earned 
Value Management, EVM) afin d’inclure le concept d’echeancier acquis (Earned Schedule, ES). 

L’echeancier acquis est une extension, en theorie et en pratique, de la gestion de la valeur acquise (EVM). La theorie 
de I'echeancier acquis (Earned Schedule, ES) remplace les mesures de I'ecart de delais utilisees dans le cadre de la 
gestion de la valeur acquise traditionnelle (valeur acquise - valeur planifiee) par un echeancier acquis et le temps reel 
(Actual Time, AT). Selon I’autre formule de calcul de I'ecart de delais, ES-AT, si la valeur de I’echeancier acquis est 
superieure a 0, le projet est considere en avance sur I’echeancier. En d’autres termes, le projet a acquis plus que planifie 
a un moment donne. L’indice de performance des delais (Schedule Performance Index, SPI) utilisant les metriques 
de I’echeancier acquis est I'echeancier acquis (ES)/le temps reel (AT) : ES/AT. II indique I’efficience avec laquelle le 
travail est accompli. La theorie de I'echeancier acquis offre egalement des formules qui permettent de prevoir la date 
d’achevement du projet grace a I'echeancier acquis, au temps reel et a la duree estimee. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 

Chaque projet etant unique, il peut s’averer necessaire pour le chef de projet d’adapter lafagon dont les processus 
de gestion des couts du projet sont appliques. Parmi les considerations relatives a I’adaptation, on peut citer les 
elements suivants: 

♦ Gestion des connaissances. ^organisation dispose-t-elle d’un systeme d’archivage formel facilement 
accessible pour les bases de donnees financieres et la gestion des connaissances, que le chef de projet esttenu 
d’utiliser ? 

♦ Estimation et etablissement du budget. L'organisation a-t-elle mis en place des politiques, des procedures et 
des directives, formelles et informelles, relatives a I’etablissement du budget et a I’estimation des couts ? 

♦ Gestion de la valeur acquise. L'organisation utilise-t-elle la gestion de la valeur acquise pour manager ses 
projets ? 

♦ Utilisation de I’approche agile. L'organisation utilise-t-elle les methodologies agiles pour manager ses projets ? 
Dans quelle mesure ces methodologies impactent I’estimation des couts ? 

♦ Gouvernance. L’organisation a-t-elle mis en place des politiques, des procedures et des directives, formelles et 
informelles, relatives a la gouvernance et a I’audit ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

En raison des changements frequents, les projets qui presentent un haut degre d'incertitude ou ceux dont le perimetre 
n’est pas encore completement defini, peuvent ne pas beneficier de calculs de couts detailles. Cependant, des methodes 
simplifies d’estimation peuvent etre utilisees pour estimer rapidement a haut niveau les couts de main-d’oeuvre du 
projet, qui peuvent alors etre facilement ajustes en cas de changement. Les estimations detaillees sont reservees a des 
horizons de planification a court terme en mode«juste a temps». 

Lorsque des projets a forte variability sont egalement soumis a des contraintes budgetaires, le perimetre 
et I’echeancier sont plus souvent ajustes afin de respecter les contraintes de cout. 
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7.1 PLANIFIER LA GESTION DES COUTS 


Planifier la gestion des couts est le processus qui consiste a definir la maniere dont les couts du projet seront 
estimes, budgetes, geres, suivis et martrises. L’interet principal de ce processus est qu’il fournit les directives et les 
orientations sur la fagon de gerer les couts du projet tout au long du projet. Ce processus est execute une fois ou a des 
moments predefinis dans le cadre du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie 
de ce processus sont presentes a la figure 7-2. La figure 7-3 presente le diagramme de flux de donnees du processus. 


Planifier la gestion des couts 


Donnees d’entree 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion 
de I'echeancier 

• Plan de gestion des risques 
.3 Facteurs environnementaux 

de I'organisation 
.4 Actifs organisationnels 

V___/ 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Analyse des donnees 
.3 Reunions 

V_/ 


[ 


Donnees de sortie 


1 Plan de gestion des couts 




Figure 7-2. Planifier la gestion des couts: donnees d’entree, outils, techniques et donnees de sortie 



• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 7-3. Planifier la gestion des couts: diagramme de flux de donnees 
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La gestion des couts se planifie tot dans la planification du projet et met en place le cadre dans lequel chacun 
des processus de gestion des couts sera execute, afin qu’il soit efficace et coordonne. Les processus de gestion des 
couts, ainsi que les outils et techniques associes, sont documents dans le plan de gestion des couts. Ce plan est une 
composante du plan de management du projet. 


7.1.1 PLANIFIER LA GESTION DES COOTS : DONNEES D’ENTREE 

7.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.2.3.1. La charte du projet comprend les ressources financieres preapprouvees a partir 
desquelles les couts detailles du projet sont determines. En outre, elle definit les exigences d’approbation du projet qui 
ont un impact sur la gestion des couts du projet. 

7.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I’echeancier etablit 
les criteres et les activites pour I’etablissement, le suivi et la maitrise de I’echeancier. Le plan de gestion de 
I'echeancier presente les processus et les controles qui auront un impact sur I’estimation et la gestion des couts. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques fournit une 
approche pour identifier, analyser et suivre les risques. Le plan de gestion des risques decrit les processus et les 
controles qui impacteront I'estimation et la gestion des couts. 

7.1.1.3 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion des couts, on peut citer les elements suivants: 

♦ La culture et la structure de I'organisation peuvent influencer la gestion des couts. 

♦ Les conditions du marche indiquent quels produits, services et resultats sont disponibles dans les marches 
regionaux et international. 

♦ Les taux de change appliques aux couts du projet emanent de plusieurs pays. 


236 


Premiere partie - Guide 



♦ Les informations commerciales publiees, telles que le cout des ressources, sont souvent disponibles dans 
les bases de donnees commerciales qui documentent le cout des ressources humaines en fonction de leurs 
competences etfournissent des couts standards de materiaux et d’equipements. Les listes de prix que publient 
les fournisseurs offrent d’autres sources d’informations. 

♦ Le systeme d’information de management du projet fournit des alternatives de gestion des couts. 

♦ Les differences de productivity dans differentes regions du monde peuvent avoir une grande influence sur le cout 
des projets. 

7.1.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion des couts, on 
peut citer: 

♦ des procedures de controle de gestion (par exemple, le systeme de pointage du temps de travail, les revues de 
depenses et de debours, les codes d’imputation et les provisions contractuelles ordinaires); 

♦ les donnees historiques et I’archive des retours d’experience ; 

♦ les bases de donnees financieres; 

♦ les politiques, les procedures et les directives existantes, formelles et informelles, relatives a I’etablissement du 
budget et a I'estimation des couts. 

7.1.2 PLANIFIER LA GESTION DES COOTS : OUTILS ET TECHNIQUES 
7.1.2.1 JUGEMENTA DIRE D’EXPERT 

II convient de faire appel a la competence decrite a la section 4.1.2.1 de personnes ou de groupes ayant une 
connaissance specialist ou une formation relatives aux themes suivants: 

♦ projets anterieurs similaires ; 

♦ informations concernant le secteur d’activite, la discipline et le domaine d’application ; 

♦ estimation des couts et etablissement du budget; 

♦ gestion de la valeur acquise. 
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7.1.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figure notamment I’analyse 
des alternatives. Cette technique peut inclure I'examen des options strategies de financement, telles que 
I'autofinancement, le financement par prise de participation ou le financement par emprunt. Elle peut egalement 
etudier les fagons d’obtenir les ressources du projet, comme la fabrication, I’achat, la location ou le leasing. 

7.1.2.3 REUNIONS 

Les equipes projet peuvent tenir des reunions de planification pour elaborer le plan de gestion des couts. Les 
participants a ces reunions peuvent compter le chef et le sponsor du projet, des membres selectionnes de I’equipe 
projet, certaines des autres parties prenantes, toute personne ayant la responsabilite des couts du projet ainsi que 
d’autres personnes, selon les besoins. 


7.1.3 PLANIFIER LA GESTION DES COOTS : DONNEES DE SORTIE 
7.1.3.1 PLAN DE GESTION DES COUTS 

Le plan de gestion des couts est une composante du plan de management du projet et decrit comment les couts du 
projet seront planifies, structures et maitrises. Les processus de gestion des couts, les outils et techniques associes sont 
documents dans le plan de gestion des couts. 

Le plan de gestion des couts permet, par exemple, d’etablir les elements suivants : 

♦ Unites de mesure. Chacune des unites de mesure utilisees sera definie pour chacune des ressources (par 
exemple, les hommes-heures/jours/semaines pour la mesure du temps ; les metres, les litres, les tonnes, les 
kilometres et les metres cubes pour les mesures de quantite ou un montant forfaitaire dans une devise donnee). 

♦ Niveau d’exactitude. II determine les regies pour arrondir les estimations des couts (995,59 dollars arrondis 
a 1 000 dollars, par exemple) en fonction du perimetre des activites et de I'ampleur du projet. 

♦ Niveau d’exactitude. La plage acceptable (±10 %, par exemple), permettant de determiner des estimations des 
couts realistes, peut comprendre une provision pour aleas. 
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♦ Liens avec les procedures de I’organisation. L'organigramme des travaux du projet (work breakdown 
structure, WBS) (voir la section 5.4) fournit le cadre du plan de gestion des couts, en assurant une coherence des 
estimations, des budgets et de la maTtrise des couts. Le composant du WBS utilise pour la comptabilite analytique 
du projet s’appelle centre de consolidation. Chaque centre de consolidation porte un code ou un numero de 
compte unique, qui le relie directement au systeme de comptabilite de I'organisation realisatrice. 

♦ Seuils de maltrise. Des seuils d'ecarts peuvent etre specifies pour le suivi de la performance des couts, afin de 
preciser un niveau d’ecart convenu comme acceptable avant qu’une action ne devienne necessaire. Ces seuils 
sont habituellement exprimes en deviation (en pour cent) par rapport au plan de reference de base. 

♦ Regies de mesure de performance. Des regies de mesure de performance sont etablies pour la gestion de la 
valeur acquise (Earned Value Management, EVM). Le plan de gestion des couts peut, par exemple : 

■ definir les points du WBS oil les evaluations des centres de consolidation seront effectuees ; 

■ etablir les techniques de gestion de la valeur acquise qui seront utilisees (par exemple, des jalons ponderes, 
des formules fixes et le pourcentage d'avancement); 

■ specifier les methodologies de suivi et les formules de calcul de la gestion de la valeur acquise (Earned Value 
Management, EVM), afin d’etablir des previsions du cout estime a terminaison et de fournir une verification 
de la validite du calcul ascendant de ce cout. 

♦ Formats de rapport. Les formats des differents rapports sur les couts, ainsi que leur frequence, sont definis. 

♦ Informations complementaires. Les informations complementaires sur les activites de gestion des couts 
comprennent, en particulier: 

■ la description des choix strategies de financement; 

■ la procedure de prise en compte des variations des taux de change ; 

■ la procedure d’enregistrement des couts du projet. 

Pour plus d’informations specifies sur la gestion de la valeur acquise, voir le Practice Standard for Earned Value 
Management-Second Edition (en anglais seulement) [17], 
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7.2 ESTIMER LES COUTS 


Estimer les couts est le processus qui consiste a evaluer le cout des ressources necessaires a I'accomplissement 
des travaux du projet. L’interet principal de ce processus reside dans le fait qu’il determine les ressources monetaires 
necessaires a I'accomplissement du projet. Ce processus est execute periodiquement pendant toute la duree du projet. 
Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 7-4. 
La figure 7-5 presente le diagramme de flux de donnees du processus. 


Estimer les couts 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion des couts 

• Plan de gestion de la qualite 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Besoins en ressources 

• Registre des risques 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V 


.1 Jugement a dire d’expert 
.2 Estimation par analogie 
.3 Estimation parametrique 
.4 Estimation ascendante 
.5 Estimation a trois points 
.6 Analyse des donnees 

• Analyse des alternatives 

• Analyse de la reserve 

• Cout de la qualite 
.7 Systeme d’information 

de gestion du projet (Project 

Management Information 

System, PMIS) 

.8 Prise de decision 

• Vote 

V_ 


.1 Estimations de couts 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Registre des retours 
d'experience 

• Registre des risques 

V ___/ 


Figure 7-4. Estimer les couts: donnees d’entree, outils, techniques et donnees de sortie 
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• Registre des risques 
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de I’organisation 

• Actifs organisationnels 


Figure 7-5. Diagramme de flux de donnees du processus Estimer les couts 
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L’estimation des couts est une evaluation quantitative du cout probable des ressources necessaires pour realiser 
I'activite. Cette prevision est basee sur les informations disponibles a un moment donne. Elle comprend I'identification 
et la prise en compte de diverses possibility d’etablissement des couts pour lancer et achever un projet. Afin d’atteindre 
un cout de projet optimal, des compromis entre couts et risques devraient etre considers, tels que produire au lieu 
d’acheter, acheter au lieu de louer et le partage des ressources. 

L’estimation des couts s’exprime generalement en unites monetaires (dollars, euros, yens, etc.), bien que, dans certains 
cas, d'autres unites de mesure (telles que les homme-heures/jours) soient utilisees pour faciliter les comparaisons en 
eliminant les effets des variations des devises. 

L'estimation des couts doit etre passee en revue et affinee au cours du projet pour refleter les informations 
complementaires au fur et a mesure qu’elles deviennent disponibles et que les hypotheses sont verifiees. L’exactitude 
d’une estimation du projet augmentera au fur et a mesure de I'avancement du projet dans son cycle de vie. Par exemple, 
un projet, dans sa phase d'initialisation, peut avoir un ordre de grandeur avec une marge d’incertitude allant de -25 % 
a +75 %. Ulterieurement, lorsque de plus amples informations deviennent disponibles, les estimations seront plus 
exactes et la marge d'imprecision peut se ramener aux environs de -5 % a +10 %. Certaines organisations disposent de 
directives sur la planification dans le temps, sur le moment oil des affinements peuvent etre apportes, et sur le niveau 
d’exactitude attendu. 

Les couts sont estimes pour toutes les ressources qui seront imputees au projet. Cela comprend, entre autres, la 
main-d’oeuvre, les materiaux, I’equipement, les services et les installations, ainsi que des categories speciales, telles 
qu’une reserve contre I’inflation, le cout du financement ou une provision pour aleas de cout. Les estimations des couts 
peuvent etre presentees au niveau de chacune des activites ou sous une forme synthetique. 


7.2.1 ESTIMER LES COOTS : DONNEES D’ENTREE 

7.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. Le plan de gestion des couts decrit les methodes 
d'estimation qui peuvent etre utilisees et le niveau d'exactitude et de precision requis pour l’estimation des couts. 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. Le plan de gestion de la qualite decrit les activites 
et les ressources necessaires pour que I’equipe de management de projet puisse atteindre les objectifs du projet 
en termes de qualite. 
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♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre 
comprend I'enonce du perimetre du projet, le WBS et le dictionnaire du WBS. 

■ Enonce du perimetre du projet. L'enonce du perimetre (voir la section 5.3.3.1) reflete les contraintes de 
financement par periode applicables a I’utilisation des fonds du projet ou d'autres hypotheses et contraintes 
financiers. 

■ Organigramme des travaux du projet (Work Breakdown Structure, WBS). Le WBS (voir la section 5.4.3.1) 
indique les relations entre tous les livrables du projet et leurs divers composants. 

■ Dictionnaire du WBS. Le dictionnaire du WBS (voir la section 5.4.3) et les enonces detailles des travaux 
fournissent une identification des livrables et une description du travail de chacun des composants du WBS 
qui sont necessaires a la production de chacun des livrables. 

7.2.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4. 3.1. Les retours d’experience en debut du projet, 
relatifs a I’estimation de la duree et de I’effort, peuvent etre appliques aux phases ulterieures afin d’ameliorer 
I’exactitude des estimations des couts. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L’echeancier contient les heures (type et quantite) 
pendant lesquelles les ressources physiques et de I'equipe contribueront au projet. Les estimations de durees 
(voir la section 6.4.3.1) influent sur les estimations des couts lorsque les ressources sont imputees par unite de 
temps et en cas de variation saisonniere des couts. L'echeancier fournit egalement des informations utiles pour 
les projets qui integrent le cout de financement (y compris le montant des interets). 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Les besoins en ressources permettent d'identifier 
les types et les quantites de ressources necessaires a chaque lot de travaux ou activite. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques detaille les risques individuels 
du projet qui ont ete identifies et classes par ordre de priorite et qui necessitent une reponse. II fournit des 
informations detaillees qui peuvent etre utilisees pour estimer les couts. 
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7.2.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Estimer les 
couts, on peut citer les elements suivants : 

♦ Conditions du marche. Les conditions du marche decrivent les produits, les services et les resultats qui sont 
disponibles sur le marche, leurs fournisseurs et les conditions generates les regissant. Les conditions, regionales 
ou internationales, de I’offre et de la demande ont un impact tres important sur le cout des ressources. 

♦ Informations commerciales publiees. Les informations sur le cout des ressources sont souvent disponibles 
dans les bases de donnees commerciales qui documentent le cout des ressources humaines selon leurs 
competences et fournissent des couts standards pour les materiaux et les equipements. Les listes de prix que 
publient les fournisseurs off rent d’autres sources d’informations. 

♦ Taux de change et inflation. Pour les projets a grande echelle qui s'etalent sur plusieurs annees avec diverses 
devises, les fluctuations de ces dernieres et I'inflation doivent etre comprises et integrees au processus Estimer 
les couts. 

7.2.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Estimer les couts, on peut citer: 

♦ les politiques d’estimation des couts ; 

♦ les modeles d'estimation des couts ; 

♦ les donnees historiques et I’archive des retours d’experience. 

7.2.2 ESTIMER LES COOTS : OUTILS ET TECHNIQUES 
7.2.2.1 JUGEMENTA DIRE D’EXPERT 

II convient de faire appel a la competence de personnes ou de groupes (decrite a la section 4.1.2.1) ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ projets anterieurs similaires ; 

♦ informations concernant le secteur d’activite, la discipline et le domaine d’application ; 

♦ modeles d’estimation des couts. 
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1 . 2 . 2.2 ESTIMATION PAR ANALOGIE 


Elle est decrite a la section 6.4.2.2. L'estimation par analogie utilise les valeurs ou les attributs d’un projet anterieur 
similaire au projet en cours. Les valeurs et attributs des projets peuvent comprendre, entre autres, le perimetre, le cout, 
le budget, la duree et les mesures de grandeur (taille, poids, etc.). La comparaison de ces valeurs ou attributs devient la 
base d’estimation du meme parametre ou de la meme mesure dans le cadre du projet en cours. 

7.2.2.3 ESTIMATION PARAMETRIQUE 

Elle est decrite a la section 6.4.2.3. L'estimation parametrique utilise une relation statistique entre les donnees 
historiques et d’autres variables (par exemple, la superficie de construction en metres carres) pour estimer les couts 
d’une activite du projet. Cette technique permet d’obtenir des resultats d’un plus grand niveau d’exactitude, en relation 
avec la sophistication du modele et les donnees qu’il comporte. Les estimations parametriques des couts peuvent 
etre appliquees a un projet complet, ou a des parties d’un projet, et peuvent etre utilisees conjointement avec d’autres 
methodes d'estimation. 

7.2.2.4 ESTIMATION ASCENDANTE 

Elle est decrite a la section 6.4.2.5. L’estimation ascendante est une methode d’estimation d’une composante du 
travail. Le cout de chaque lot de travaux ou de chaque activite est estime au niveau le plus detaille. Ces couts detailles 
sont ensuite totalises ou«remontes»vers des niveaux superieurs pour permettre I'etablissement de rapports et le suivi. 
Le cout et I'exactitude de l'estimation ascendante sont generalement fonction de la taille et de la complexity de chaque 
activite ou de chaque lot de travaux. 

7.2.2.5 ESTIMATION A TROIS POINTS 

Elle est decrite a la section 6.4.2.4. L'exactitude des estimations basees sur une seule valeur peut etre grandement 
amelioree en considerant I'incertitude et le risque de l’estimation et en utilisanttrois estimations pour definir une plage 
de cout: 

♦ Plus probable (cPP). Le cout de I'activite, base sur une evaluation realiste du travail necessaire et des 
depenses prevues. 

♦ Optimiste (cO). Le cout de I’activite base sur I’analyse du« meilleur scenario possible». 

♦ Pessimiste ( cP ). Le cout de I’activite base sur I’analyse du« pire scenario possible». 
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En fonction de la repartition supposee des valeurs contenues dans la plage des trois estimations, le cout escompte 
(cE) peut etre calcule a I’aide d’une formule. La distribution triangulaire et la distribution beta sont deux formules 
souvent utilisees. En voici le detail: 

♦ Distribution triangulaire. cE = (cO + cPP + cP)/ 3 

♦ Distribution beta. cE = (cO + 4cPP+ cF)/ 6 

Les estimations des couts basees sur les trois points avec une distribution definie donnent un cout escompte et 
precisent la plage d’incertitude autour de ce cout. 

7.2.2.6 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees qui peuvent etre utilisees lors du processus Estimer les couts figurent 
notamment les elements suivants : 

♦ Analyse des alternatives. Cette technique est utilisee pour evaluer et selectionner des options, ou approches, 
identifies pour realiser et executer les travaux du projet. Par exemple, I’impact sur les couts, I’echeancier, les 
ressources et la qualite est evalue pour I'achat en comparaison avec la production d’un livrable. 

♦ Analyse de la reserve. Les estimations des couts peuvent inclure des reserves pour aleas (que I’on appelle 
parfois allocations pour aleas), afin de tenir compte des incertitudes sur les couts. Les reserves pour aleas 
correspondent au budget dans la reference de base des couts qui est alloue pour couvrir les risques identifies. 
Les reserves pour aleas sont souvent considerees comme la part du budget destinee a couvrir les incertitudes 
identifies susceptibles d’influencer sur un projet. Par exemple, une reprise d’un livrable du projet peut etre 
anticipee, quand bien meme I’ampleur de cette reprise est inconnue. Les reserves pour aleas peuvent etre 
estimees afin de prendre en compte I'ampleur inconnue de la reprise. Elies peuvent etre fournies a tout niveau, 
de I’activite specifique au projet dans son ensemble. Les reserves pour aleas peuvent etre exprimees sous forme 
d’un pourcentage du cout estime de I'activite ou par un nombre fixe ou encore etre determinees a partir de 
methodes d’analyse quantitative. 

Au fur et a mesure que des informations plus exactes sur le projet deviennent disponibles, les reserves pour 
aleas peuvent etre utilisees, reduites ou supprimees. Ces reserves doivent etre clairement identifies dans la 
documentation des couts. Les reserves pour aleas font partie de la reference de base des couts et des besoins 
globaux de financement du projet. 

♦ Cout de la qualite. Des hypotheses relatives au cout de la qualite (voir la section 8.1.2.3) peuvent etre utilisees 
pour la preparation des estimations. Elies evaluent notamment I’impact en termes de cout d’un investissement 
supplemental en vue de produire un resultat conforme par rapport au cout d’une non-conformite. Elies peuvent 
egalement comparer des reductions de cout a court terme avec les consequences de problemes plus frequents 
ulterieurement dans le cycle de vie du produit. 
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7.2.2.7 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Le systeme d'information de management du projet peut comprendre des feuilles de 
calcul, des logiciels de simulation et des outils d’analyse statistique qui aident a estimer les couts. Ces outils simplifient 
I’utilisation de certaines techniques d’estimation des couts et facilitent ainsi une etude rapide de diverses possibilites 
d’estimation des couts. 

7.2.2.8 PRISE DE DECISION 

Parmi les techniques de prise de decision qui peuvent etre utilisees lors du processus Estimer les couts figurent 
notamment les elements suivants : Decrit a la section 5.2.2.4, le vote est un processus devaluation de possibilites 
multiples dont on attend comme resultat la decision d’entreprendre de futures actions. Ces techniques permettent de 
mobiliser les membres de I’equipe projet en vue d’ameliorer I’exactitude des estimations et I’engagement envers les 
estimations fournies. 


7.2.3 ESTIMER LES COOTS : DONNEES DE SORTIE 
7.2.3.1 ESTIMATIONS DES COUTS 

Les estimations des couts incluent des evaluations quantitatives des couts probablement necessaires pour accomplir 
les travaux du projet, ainsi que les montants des aleas pour les risques identifies et la reserve pour imprevus destinee 
a couvrir les travaux non planifies. Les estimations des couts peuvent etre presentees sous une forme resumee ou 
sous une forme detaillee. Les couts sont estimes pour tous les types de ressources pris en compte dans le cadre de 
ce processus. Cela comprend, entre autres, la main-d’oeuvre directe, les materiaux, I’equipement, les services, les 
installations et les technologies de I’information, ainsi que des categories speciales, telles que le cout du financement 
(y compris le montant des interets), une reserve pour I’inflation, les taux de change ou une reserve pour aleas. S’ils sont 
inclus dans I’estimation du projet, les couts indirects peuvent figurer au niveau de I’activite ou a des niveaux superieurs. 


246 


Premiere partie - Guide 



7.2.3.2 BASE DES ESTIMATIONS 


Le volume et le type de details supplemental utilises dans I'estimation des couts dependent du domaine 
d’application. Quel que soit le niveau de detail, la documentation fournie doit permettre une comprehension claire et 
exhaustive de la fagon dont I'estimation des couts a ete obtenue. 

Les details a I’origine des estimations des couts peuvent comprendre: 

♦ une documentation sur les bases de I'estimation (c’est-a-dire sur la fagon dont elle a ete etablie); 

♦ la documentation de toutes les hypotheses formulees ; 

♦ la documentation de toutes les contraintes connues ; 

♦ la documentation des risques identifies au moment de I'estimation des couts ; 

♦ I'indication des plages d’estimation possibles (par exemple, 10 000 dollars (±10 %) pour montrer qu’il est prevu 
que le cout de I’element se situe dans cette plage); 

♦ I’indication du niveau de confiance de I’estimation finale. 

7.2.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Au cours du processus Estimer les couts, de nouvelles 
hypotheses peuvent etre formulees, de nouvelles contraintes peuvent etre identifies et les hypotheses ou les 
contraintes existantes peuvent etre revues et changees. Le journal des hypotheses doit etre mis a jour afin 
d’inclure ces nouvelles informations. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour afin d’inclure les techniques qui se sont averees efficaces dans I’etablissement des estimations 
des couts. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques peut etre mis a jour lorsque des 
reponses appropriees aux risques sont choisies et validees au cours du processus Estimer les couts. 
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7.3 DETERMINER LE BUDGET 


Determiner le budget est le processus qui consiste a consolider les couts estimes, de chacune des activites ou de 
chacun des lots de travaux, afin d’etablir une reference de base des couts approuvee. L’interet principal de ce processus 
est qu’il determine la reference de base des couts qui peut etre utilisee comme element de comparaison pour suivre la 
performance du projet. Ce processus est execute au moins une fois ou a plusieurs moments predefinis durant le projet. 
Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 7-6. 
La figure 7-7 presente le diagramme de flux de donnees du processus. 

Un budget du projet comprend I’ensemble des fonds autorises pour I’execution du projet. La reference de base des 
couts est la version approuvee du budget echelonne du projet. Elle comprend les reserves pour aleas, mais pas les 
reserves pour imprevus. 


Determiner le budget 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion des couts 

• Plan de gestion 
des ressources 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Base des estimations 

• Estimations de couts 

• Echeancier du projet 

• Registre des risques 
.3 Documents business 

• Business case 

• Plan de gestion 
des benefices 

.4 Accords 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
V___ 


.1 Jugement a dire d'expert 
.2 Consolidation des couts 
.3 Analyse des donnees 
• Analyse de la reserve 
.4 Revue des donnees 
historiques 

.5 Reconciliation des limites 
de financement 
.6 Financement 

V_ 


A Reference de base des couts 
.2 Besoin en financement 
du projet 

.3 Mises a jour des documents 
du projet 

• Estimations de couts 

• Echeancier du projet 

• Registre des risques 

V ___/ 


Figure 7-6. Determiner le budget: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 7-7. Diagramme de flux de donnees du processus Determiner le budget 
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7.3.1 DETERMINER LE BUDGET : DONNEES D’ENTREE 


7.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. Le plan de gestion des couts decrit la fagon dont les 
couts du projet seront structures dans le budget du projet. 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources fournit des 
informations sur les couts (personnel et autres ressources), I’estimation des frais de deplacement et les autres 
couts prevus qui sont necessaires pour estimer le budget global du projet. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre comprend 
I'enonce du perimetre du projet, le WBS et le dictionnaire du WBS pour la gestion et I’estimation des couts. 

7.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Base des estimations. Elle est decrite a la section 6.4.3.2. Les details a I’origine des estimations des couts 
sont documents dans la base des estimations. Ils indiquent toutes les hypotheses fondamentales concernant 
I'inclusion ou I’exclusion de couts indirects, ou d’autres couts, dans le budget du projet. 

♦ Estimations des couts. Elies sont decrites a la section 7.2.3.1. Le cumul des estimations des couts de chacune 
des activites d’un lot de travaux permet d’obtenir I’estimation des couts de ce lot de travaux. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L’echeancier du projet comprend les dates de debut et 
de fin des activites du projet, les jalons, les lots de travaux et les centres de consolidation. Ces informations 
permettent de cumuler les couts pour chacune des periodes calendaires au cours desquelles il est prevu que les 
couts soient encourus. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques doit etre analyse afin de prendre 
en compte le cumul des couts des reponses aux risques. Les mises a jour des documents du projet decrites a la 
section 11.5.3.3. comprennentcelles du registre des risques. 
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7.3.1.3 DOCUMENTS BUSINESS 


Ms sont decrits a la section 1.2.6. Parmi les documents business susceptibles d'etre considers comme des donnees 
d’entree pour ce processus figurent notamment les elements suivants : 

♦ Business case. Le business case identifie les facteurs essentiels a la reussite du projet, notamment les facteurs 
de reussite sur le plan financier. 

♦ Plan de gestion des benefices. Le plan de gestion des benefices comprend les benefices cibles, tels que les 
calculs de la valeur actuelle nette, le delai d’obtention des benefices et les metriques associees aux benefices. 

7.3.1.4 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les informations et les couts des accords relatifs aux produits, aux services ou 
aux resultats, qui ont ete achetes ou qui le seront, sont pris en compte lors de la determination du budget. 

7.3.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Estimer 
les couts figurent notamment les taux de change. Pour les projets a grande echelle qui s'etalent sur plusieurs annees 
avec diverses devises, les fluctuations de ces dernieres doivent etre comprises et integrees au processus Determiner 
le budget. 

7.3.1.6 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Determiner le budget, on peut citer: 

♦ les politiques, les procedures et les directives existantes, formelles et informelles, et relatives a I'etablissement 
du budget; 

♦ les donnees historiques et I’archive des retours d’experience ; 

♦ les outils de preparation du budget; 

♦ les methodes d’etablissement des rapports. 
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7.3.2 DETERMINER LE BUDGET : OUTILS ET TECHNIQUES 


7.3.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II taut considerer I'expertise d’individus ou de groupes ayant une connaissance 
specialist ou une formation dans les domaines suivants: 

♦ projets anterieurs similaires ; 

♦ informations concernant le secteur d’activite, la discipline et le domaine d’application ; 

♦ principes financiers; 

♦ besoins et sources de financement. 

7.3.2.2 CONSOLIDATION DES COUTS 

Les estimations des couts sont cumulees par lot de travaux, conformementau WBS. Les estimations des couts des 
lots de travaux sont ensuite cumulees pour les niveaux superieurs des composants du WBS (tels que les centres de 
consolidation) et in fine pour I’ensemble du projet. 

7.3.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees qui peuvent etre utilisees dans le processus Determiner le budget figure 
I'analyse de la reserve, qui permet d’etablir les reserves pour imprevus du projet. II s'agit d’un montant du budget du 
projet reserve pour la marge de manoeuvre du management. II est destine a des travaux imprevus qui font partie du 
perimetre du projet. Les reserves pour imprevus permettent de gerer les evenements non anticipables (inconnu-inconnu) 
susceptibles d’influencer un projet. Elies ne font pas partie de la reference de base des couts, mais du budget et des 
besoins de financement de I’ensemble du projet. Lorsque le montant des reserves pour imprevus est utilise pourfinancer 
des taches non anticipees, il est ajoute a la reference de base des couts. Ceci doit faire I’objet d’un changement approuve. 
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7.3.2.4 REVUE DES DONNEES HISTORIQUES 

La revue des donnees historiques peut permettre d'elaborer des estimations parametriques ou des estimations par 
analogie. Elies peuvent inclure, entre autres, les caracteristiques du projet (parametres) qui permettront de developper 
des modeles mathematiques afin de prevoir les couts totaux du projet. Ces modeles peuvent etre simples (par exemple, 
la construction d’une maison residentielle coutera un certain prix au metre carre habitable) ou complexes (par exemple, 
la modelisation du cout de developpement d’un logiciel utilise plusieurs facteurs d’ajustement distincts, chacun d’eux 
comportant plusieurs criteres). 

Le cout et I’exactitude des modeles analogiques ou parametriques peuvent varier considerablement. Ces modeles 
seront probablement d’autant plus fiables que : 

♦ les donnees historiques utilisees pour developper le modele seront plus precises ; 

♦ les parametres utilises dans le modele seront facilement quantifiables ; 

♦ les modeles seront extensibles et pourront aussi bien convenir a de grands projets qu’a de petits projets, ou aux 
phases d’un projet. 

7.3.2.5 RECONCILIATION DES LIMITES DE FI NAN CEMENT 

Les depenses de fonds doivent etre rapprochees avec les limites de financement fixees lors des engagements 
de fonds du projet. Un ecart entre les limites de financement et les depenses planifiees necessitera parfois une 
modification de la planification du travail afin de mieux repartir les depenses. Cela se fait en imposant des contraintes 
de dates sur le travail dans I'echeancier du projet. 

7.3.2.6 FINANCEMENT 

Le financement suppose d’obtenir des fonds pour les projets. II est frequent, pour les projets a long terme dans le 
domaine des services publics, de I’industrie et des infrastructures, de rechercher des financements aupres de sources 
externes. Si un projet est finance par une source externe, cette entite peut emettre certaines exigences qui doivent 
etre respectees. 
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7.3.3 DETERMINER LE BUDGET : DONNEES DE SORTIE 


7.3.3.1 REFERENCE DE BASE DES COUTS 

La reference de base des couts est la version approuvee du budget echelonne dans le temps du projet, excluanttoute 
reserve pour imprevus, qui ne peut etre changee qu'atravers les procedures formelles de martrise des changements. 
Elle permet de faire des comparaisons avec les resultats reels. La reference de base des couts est etablie en additionnant 
les budgets approuves pour les differentes activites de I’echeancier. 

La figure 7-8 illustre les divers composants du budget du projet et de la reference de base des couts. Les estimations 
des couts des differentes activites du projet, avec les reserves pour aleas (voir la section 7.2.2.6) pour ces activites, 
sont cumulees afin d’obtenir les couts correspondants du lot de travaux. Les estimations des couts du lot de travaux, 
comprenant les reserves pour aleas relatives a ces lots de travaux, sont cumulees au niveau des centres de consolidation. 
La reference de base des couts est constitute du total des couts des centres de consolidation. Les estimations des couts 
composant la reference de base des couts sont directement liees aux activites de I’echeancier, ce qui fournit une vue 
echelonnee de la reference de base des couts. Cette vue est generalement presentee sous la forme d’une courbe en S, 
comme le montre la figure 7-9. Pour les projets qui utilisent la gestion de la valeur acquise, la reference de base des 
couts correspond a la reference de base de la performance. 

Les reserves pour imprevus (voir la section 7.2.2.3) sont ajoutees a la reference de base des couts afin d'etablir le 
budget du projet. Au fur et a mesure que des changements justifiant I’utilisation des reserves pour imprevus surviennent, 
le processus de maitrise des changements permet d’obtenir I’approbation requise pour transferer les fonds concernes 
des reserves pour imprevus dans la reference de base des couts. 
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Figure 7-8. Composants du budget du projet 
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Figure 7-9. Reference de base des couts, depenses et besoins de financement 
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7.3.3.2 BESOINS DE FINANCEMENT DU PROJET 


Les besoins de financement total et periodique du projet (par exemple, trimestriel ou annuel) sont derives de la 
reference de base des couts. Cette reference de base comprend les depenses prevues et les dettes anticipees. Le 
financement s'effectue souvent par montants incrementaux, susceptibles de ne pas etre repartis de fagon uniforme, qui 
sont presentes par des marches a la figure 7-9. Le total des fonds requis se compose des couts inclus dans la reference 
de base des couts plus, le cas echeant, des reserves pour imprevus. Les besoins de financement peuvent comprendre 
la ou les sources de financement. 

7.3.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Estimations des couts. Elies sont decrites a la section 7.2.3.1. Les estimations des couts sont mises a jour afin 
d’inclure toute information supplemental. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. Les couts estimes de chaque activite peuvent etre 
enregistres dans I'echeancier du projet. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 
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7.4 MAITRISER LES COOTS 

MaTtriser les couts est le processus qui consiste a suivre I’etat du projet pour mettre a jour les couts du projet et 
gerer les changements affectant la reference de base des couts. L’interet principal de ce processus reside dans le fait 
qu’il permet de conserver la reference de base des couts tout au long du projet. Ce processus est execute tout au long 
du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 7-10. La figure 7-11 presente le diagramme de flux de donnees du processus. 


Maitriser les couts 


Donnees d’entree V Outils et techniques ■ Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion des couts 

• Reference de base 
des couts 

• Reference de base 
de la performance 

.2 Documents du projet 

• Registre des retours 
d'experience 

.3 Besoin en financement 
du projet 

.4 Donnees de performance 
d’execution 

.5 Actifs organisationnels 
V___ 


.1 Jugement a dire d'expert 
.2 Analyse des donnees 

• Analyse de la valeur acquise 

• Analyse des ecarts 

• Analyse de la tendance 

• Analyse de la reserve 
.3 Indice de performance 

a terminaison du projet 
.4 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

V___/ 


.1 Information sur 

la performance d'execution 
.2 Previsions de couts 
.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 

• Plan de gestion des couts 

• Reference de base 
des couts 

• Reference de base 
de la performance 

.5 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Base des estimations 

• Estimations de couts 

• Registre des retours 
d'experience 

• Registre des risques 

V ___/ 


Figure 7-10. Maitriser les couts: donnees d’entree, outils, techniques et donnees de sortie 


257 















• Actifs organisationnels 


Figure 7-11. Diagramme de flux de donnees du processus Maitriser les couts 
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La mise a jour du budget necessite de connaitre les couts reels encourus jusqu’a ce jour. Toute augmentation du 
budget autorise ne peut etre approuvee qu'en utilisant le processus MaTtriser les changements (voir la section 4.6). A 
part le fait de permettre de suivre la sortie des fonds, une maitrise des depenses en fonds qui ne tiendrait pas compte 
de la valeur du travail accompli n'ajouterait que peu de valeur au projet. La plus grande partie de I’effort de controle des 
couts doit porter sur I'analyse de la relation entre I’utilisation des fonds du projet et le travail reel accompli ayant entraine 
ces depenses. La cle d’une maitrise efficace des couts est la gestion de la reference de base des couts approuvee. 

La maitrise des couts du projet consiste a : 

♦ agir sur les facteurs qui engendrent des changements dans la reference de base des couts autorisee; 

♦ s'assurer que toutes les demandes de changement sont traitees en temps voulu ; 

♦ gerer les changements au fur et a mesure qu’ils se presented; 

♦ s'assurer que les depenses ne depassent pas les fonds autorises par periode, par composant du WBS, par 
activite, ainsi que pour I'ensemble du projet; 

♦ suivre la performance des couts afin d’identifier et comprendre les ecarts par rapport a la reference de base 
des couts; 

♦ suivre la performance du travail par rapport aux depenses qu’il a entrainees ; 

♦ empecher que des changements non approuves soient apportes dans les rapports ou I’utilisation des couts 
et ressources; 

♦ informer les parties prenantes concernees de tous les changements approuves et des couts associes ; 

♦ ramener les surcouts prevus dans des limites acceptables. 

7.4.1 MAITRISER LES COOTS : DONNEES D’ENTREE 

7.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants : 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. Le plan de gestion des couts decrit la fagon dont les 
couts du projet seront geres et maitrises. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts est comparee 
a I’etat reel afin de determiner si un changement, une action corrective ou preventive s’avere necessaire. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Dans le cadre de I'analyse de 
la valeur acquise, la reference de base de la performance est comparee a I'etat reel afin de determiner si un 
changement, une action corrective ou preventive s'avere necessaire. 
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7.4.1.2. DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus figure 
notamment le registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d'experience du debut du 
projet peuvent etre appliques aux phases ulterieures afin d’ameliorer la maitrise des couts. 

7.4.1.3 BESOINS DE FINANCEMENT DU PROJET 

Elies sont decrites a la section 7.3.3.2. Les besoins de financement du projet comprennent les depenses prevues et les 
dettes anticipees. 

7.4.1.4 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent les donnees sur I'etat 
du projet, comme les couts qui ont ete autorises, engages, factures et payes. 

7.4.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser les couts, on peut citer: 

♦ les politiques, les procedures et les directives existantes, formelles et informelles, relatives a la martrise des couts; 

♦ les outils de martrise des couts; 

♦ les methodes de maitrise et reporting a utiliser. 

7.4.2 MAITRISER LES COOTS : OUTILS ET TECHNIQUES 
7.4.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. Au cours du processus MaTtriser les couts, les jugements a dire d’expert suivants 
peuvent notamment avoir lieu : 

♦ analyse des ecarts; 

♦ analyse de la valeur acquise (EVM); 

♦ prevision; 

♦ analyse financier. 
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7.4.2.2 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees pour maTtriser les couts figurent notamment les 
elements suivants: 

♦ Analyse de la valeur acquise (Earned Value Analysis, EVA). L'analyse de la valeur acquise compare la reference 
de base de la performance a I’etat de I'echeancier et de la performance des couts. La gestion de la valeur acquise 
integre les references de base du perimetre, des couts et de I’echeancier pour constituer la reference de base de 
la performance. En outre, elle etablit et fait le suivi des trois valeurs cles suivantes pour chaque lot de travaux et 
chaque centre de consolidation : 

■ Valeur planifiee. La valeur planifiee (Planned Value, PV) represente le budget autorise affecte au travail prevu. Ce 
budget autorise est alloue au travail a accomplir pour une activite ou un composant du WBS, les reserves pour 
imprevus exclues. II est alloue par phases tout au long du cycle de vie du projet. Toutefois, a un moment donne, 
la valeur planifiee definit le travail effectif qui aurait du etre accompli. La valeur planifiee totale est parfois 
designee comme la reference de base de la performance (performance measurement baseline, PMB). La valeur 
planifiee totale pour le projet est egalement appelee budget a terminaison (budget at completion, BAC). 

■ Valeur acquise. La valeur acquise (Earned Value, EV) represente la mesure du travail effectue exprimee en 
termes de budget autorise pour ce travail. C’est le budget associe au travail autorise qui a ete accompli. 
La valeur acquise mesuree doit correspondre a la reference de base de la performance (performance 
measurement baseline, PMB). Par ailleurs, pour un composant, la valeur acquise mesuree ne doit pas etre 
superieure au budget approuve de la valeur planifiee (Planned Value, PV). La valeur acquise est souvent 
utilisee pour calculer le pourcentage d’avancement d’un projet. Des criteres de mesure de I'avancement 
doivent etre etablis pour chaque composant du WBS, afin de mesurer le travail en cours. Les chefs de projet 
suivent la valeur acquise, d’une part par intervalle pour etablir I’etat actuel, et d’autre part en cumule pour 
etablir les tendances de performance a long terme. 

■ Cout reel. Le cout actuel (Actual Cost, AC) represente les couts reels encourus pour le travail execute sur une 
activite, pendant une periode de temps specifique. C’est la somme des couts encourus pour accomplir le 
travail que la valeur acquise a mesure. Le cout reel doit correspondre, par definition, a ce qui a ete budgete 
pour la valeur planifiee et mesure dans la valeur acquise (par exemple, des heures de main-d’oeuvre directe 
uniquement, des couts directs uniquement ou tous les couts, y compris les couts indirects). Le cout reel n’a 
pas de limite superieure, car tout ce qui a ete depense pour obtenir la valeur acquise sera mesure. 
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♦ Analyse des ecarts. Elle est decrite a la section 4.5.2.2. Dans le cadre de la gestion de la valeur acquise, 
I’analyse des ecarts permet d’expliquer (cause, impact et actions correctives) les ecarts de couts (CV = EV-AC), 
les ecarts de delais (SV = EV - PV) et les ecarts a terminaison (VAC = BAC - EAC). Les ecarts le plus frequemment 
analyses sont ceux des couts et des delais. Pour les projets qui n’utilisent pas I’analyse de la valeur acquise, 
des analyses similaires des ecarts peuvent etre effectuees en comparant les couts planifies aux couts reels de 
I'activite, en vue d’identifier les ecarts entre la reference de base des couts et la performance du projet. II est 
possible de realiser une analyse plus approfondie afin de determiner la cause et le degre de I'ecart par rapport 
a la reference de base de I’echeancier et toute action corrective ou preventive necessaire. Les mesures de 
performance des couts permettent d’evaluer I’importance de I’ecart par rapport a la reference de base initiate 
des couts. La determination de la cause et de la gravite de I’ecart par rapport a la reference de base des couts 
(voir la section 7.3.3.1) et la determination de la necessity d’une action corrective ou preventive sont des aspects 
importants de la maitrise des couts du projet. La plage d’ecart (en pour cent) acceptable aura tendance a se 
reduire au fur et a mesure que le travail sera accompli. Parmi les exemples d’analyses des ecarts, on peut citer 
les elements suivants: 

■ Ecartde delais. L’ecart de delais (Schedule Variance, SV) represente la mesure de performance de I’echeancier 
exprimee comme la difference entre la valeur acquise et la valeur planifiee. Ce montant indique a tout moment 
a quel point le projet est en avance ou en retard par rapport a la date de livraison prevue, C'est une mesure 
de I'ecart de la performance de I’echeancier d’un projet. II est egal a la difference entre la valeur acquise et 
la valeur planifiee. Dans le cadre de I'analyse de la valeur acquise, I’ecart de delais est un indicateur utile car 
il indique le retard ou I’avance que peut prend un projet par rapport a la reference de base de I’echeancier. II 
s'annulera toujours lors de I’achevement du projet car toutes les valeurs planifiees auront alors ete acquises. 
La meilleure fagon d’utiliser I'ecart de delais est de I’associer a la planification par la methode du chemin 
critique et a la gestion des risques. Formule : SV - EV - PV. 

■ Ecartde cout. L’ecart de cout (cost variance, CV) represente le montant du deficit ou de I’excedent budgetaire 
a un point donne dans le temps, exprime comme la difference entre la valeur acquise et le cout reel. C’est 
une mesure de la performance du cout dans un projet. II est egal a la difference entre la valeur acquise et 
le cout reel. A la fin du projet, I'ecart de cout sera la difference entre le budget a terminaison et le montant 
total des depenses encourues. L’ecart de cout est particulierement critique, car il indique la relation entre 
la performance et les couts effectifs. Un ecart de cout negatif est souvent difficilement recuperable pour le 
projet. Formule : CV = EV-AC. 
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■ Indice de performance des delais. L’indice de performance des delais (Schedule Performance Index, SPI) 
represente la mesure de rendement de I'echeancier exprimee par le ratio de la valeur acquise rapportee a la 
valeur planifiee. Cet indice mesure I’efficacite avec laquelle I’equipe projet accomplit le travail. II est parfois 
utilise conjointement avec I’indice de performance des couts (cost performance index, CPI) pour prevoir les 
estimations finales d’achevement du projet. Un indice de performance des delais inferieur a 1 signifie que le 
travail est moins avance que planifie. Un indice de performance des delais superieur a 1 signifie que le travail 
est plus avance que planifie. L'indice de performance des delais etant mesure pour I'ensemble du travail, la 
performance sur le chemin critique doit egalement etre analysee pour determiner si le projet sera acheve ou 
non a la date de fin prevue. L’indice de performance des delais est egal au rapport de la valeur acquise sur la 
valeur planifiee. Formule: SPI = EV/PV. 

■ Indice de performance des couts. L'indice de performance des couts (Cost Performance Index, CPI) represente 
la mesure de rendement du cout des ressources budgetisees exprimee par le ratio de la valeur acquise 
rapportee au cout reel. Cet indice est considere comme I’indicateur le plus important de I'analyse de la valeur 
acquise : il mesure I’efficience du travail accompli en termes de couts. Un indice de performance des couts 
inferieur a 1 indique un depassement du cout pour le travail accompli. Un indice de performance des couts 
superieur a 1 indique un cout inferieur a ce jour. L'indice de performance des couts est egal au ratio de la 
valeur acquise sur le cout reel. Formule : CPI = EV/AC. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5.2.2. L'analyse de la tendance consiste a examiner 
les performances du projet dans le temps pour determiner si elles s’ameliorent ou si elles se degradent. 
Les techniques d’analyse graphique sont utiles pour comprendre la performance a ce jour. Elles permettent 
egalement de comparer la performance a ce jour aux objectifs de performance a venir, sous la forme du budget a 
terminaison (Budget At Completion, BAC) par rapport au cout estime a terminaison (estimate at completion, EAC) 
et aux dates d’achevement. Parmi les techniques d’analyse de la tendance, on peut citer les elements suivants : 

■ Diagrammes. Dans le cadre de l'analyse de la valeur acquise, les trois parametres que sont la valeur planifiee, 
la valeur acquise et le cout reel peuvent etre suivis et rapportes par periode (habituellement par semaine 
ou par mois) et de fagon cumulee. La figure 7-12 presente les donnees de valeur acquise sous la forme 
d’une courbe en S pour un projet dont le cout depasse le budget et dont le travail est en retard par rapport 
a I'echeancier. 


263 



Budget du projet 



Temps -► 


Figure 7-12. Valeur acquise, valeur planifiee et couts reels 


■ Prevision. Au cours de I’execution du projet, compte tenu de sa performance, I’equipe projet peut etablir une 
prevision du cout estime a terminaison susceptible de differer du budget a terminaison. Le chef de projet doit 
calculer un cout final estime s'il est evident que le budget a terminaison n'est plus viable. La prevision d’un 
cout final estime consiste a prevoir des situations ou des evenements a venir a partir d’informations sur la 
performance et d’autres connaissances disponibles au moment de la prevision. Les previsions sont etablies, 
mises a jour et publiees a nouveau sur la base des donnees de performance d’execution (voir la section 4.3.3.2) 
fournies au fur et a mesure de I'execution du projet. L'information sur la performance d’execution comprend la 
performance passee du projet et toutes donnees susceptibles d’avoir un impact sur la suite du projet. 

Le cout final estime comprend habituellement les couts reels encourus du travail acheve plus le cout du 
reste a faire (estimate to complete, ETC). Afin d’etablir le cout du reste a faire, il appartient a I’equipe projet 
de prevoir les situations qui peuvent se presenter, au regard de I’experience acquise. L'analyse de la valeur 
acquise fonctionne bien avec des previsions manuelles du cout final estime requis. L'approche la plus 
courante de prevision du cout final estime est une addition ascendante manuelle effectuee par le chef de 
projet et son equipe. 

La methode d’estimation ascendante du cout final estime (Bottom-up ETC) utilisee par le chef de projet est 
basee sur les couts reels et I’experience acquise au cours du travail accompli. Elle necessite la realisation 
d’une nouvelle estimation pour le cout du reste a faire. Formule : EAC = AC + Bottom-up ETC. 


264 


Premiere partie - Guide 















Le cout final estime manuellement par le chef de projet est rapidement compare a plusieurs valeurs de 
cout final estime selon differents scenarios de risque. Lors du calcul du cout final estime, les indices de 
performance des couts cumules et des delais cumules sont generalement utilises. Alors que les donnees 
provenant de la gestion de la valeur acquise fournissent plusieurs valeurs statistiques de I’EAC, seules trois 
methodes (les plus communes) sont decrites ci-apres : 

o Cout final estime base surle cout estime du reste a faire en utilisantle taux prevu. La methode d'estimation 
du cout final prend en compte la performance du projet a ce jour, qu'elle soit favorable ou non, telle que 
representee par le cout reel. En outre, elle prevoit le cout estime du reste a faire sur la base du taux prevu. 
Lorsque la performance est defavorable, I’hypothese selon laquelle la performance future va s’ameliorer 
ne peut etre acceptee que si elle est justifiee par une analyse des risques du projet. Formule: EAC = AC + 
(BAC - EV). 

o Cout final estime base sur le cout estime du reste a faire en utilisant I’indice de performance des couts. 
Cette methode suppose que les conditions dans lesquelles le projet a ete execute jusqu'a present vont 
rester les memes jusqu'a I'achevement du projet. Elle suppose egalement que le travail correspondant 
au cout estime du reste a faire va etre effectue sur la base de I’indice de performance des couts cumules 
effectif jusqu'a ce jour. Formule : EAC = BAC / CPI. 

o Cout final estime base sur le cout estime du reste a faire en utilisant les deux indices de performance des 
delais et des couts (SPI et CPI). Dans cette prevision, le travail correspondant au cout estime du reste a 
faire va etre effectue avec un rendement base a la fois sur I’indice de performance des delais et I’indice de 
performance des couts. Cette methode est d’autant plus utile que I’echeancier du projet affecte I'effort du 
cout estime du reste a faire. Cette methode pondere les indices de performance des delais et des couts. 
La ponderation choisie est laissee a (’appreciation du chef de projet et pourra etre de 80/20, de 50/50 ou 
d’un autre ratio. Formule : EAC = AC + [(BAC - EV) / (CPI x SPI)]. 

♦ Analyse de la reserve. Elle est decrite a la section 7.2.2.6. Dans le cadre de la maTtrise des couts, I'analyse de 
la reserve est utilisee pour suivre I’etat des reserves pour aleas et des reserves pour imprevus afin de determiner 
si ces reserves sont toujours necessaires ou si des reserves supplementaires doivent etre demandees. Au fur et 
a mesure de I'avancement du projet, ces reserves peuvent etre utilisees comme prevu, afin de couvrir les couts 
des reponses aux risques ou d’autres aleas. A I'inverse, lorsque des opportunity saisies permettent de faire des 
economies, des fonds peuvent etre ajoutes a la reserve pour aleas ou retires du projet a titre de marge/profit. 

Si les risques identifies ne se realisent pas, les reserves pour aleas non utilisees peuvent etre retirees du budget 
du projet. Ces ressources liberees seront disponibles pour d’autres projets ou operations. Des analyses de risques 
effectuees au cours du projet, peuvent reveler la necessity d’ajouter des reserves supplementaires au budget 
du projet. 
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7.4.2.3 INDICE DE PERFORMANCE A TERMINAISON DU PROJET 


L’lndice de performance a terminaison du projet (to-complete performance index, TCPI) represente la mesure de 
la performance des couts a atteindre avec les ressources restantes pour atteindre un objectif managerial specifie. Le 
TCPI est exprime par le ratio du cout pour terminer le travail non acheve sur le budget restant. Le TCPI est I’indice de 
performance des couts qui doit etre atteint durant le travail restant afin d’atteindre un objectif managerial specifie, tel 
que le budget a terminaison ou le cout final estime. S’il est evident que le budget a terminaison n’est plus atteignable, 
le chef de projet doit prendre en compte un cout final estime. Une fois approuve, le cout final estime remplace le 
budget a terminaison dans le calcul de I'indice de performance a terminaison du projet. La formule de I'indice de 
performance a terminaison du projet base sur le budget a terminaison est: (BAC - EV) / (BAC - AC). 

L'indice de performance a terminaison du projet est illustre de maniere conceptuelle sur la figure 7-13. L'indice de 
performance a terminaison du projet est donne par la formule indiquee en bas a gauche de la figure. Le travail restant 
a faire (defini comme le budget a terminaison moins la valeur acquise) est divise par les fonds restants (definis 
comme, selon les cas, soit le budget a terminaison moins le cout reel, soit le cout final estime moins le cout reel). 

Lorsque I’indice de performance des couts cumule se situe au-dessous de la reference de base, comme illustre 
sur la figure 7-13, tout le travail restant devra etre effectue avec I’indice de performance a terminaison du projet 
(illustre par la ligne superieure TCPI (BAC) de la meme figure) pour rester dans le budget a terminaison autorise. 
Que cette performance soit realisable ou non est affaire de jugement, prenant en compte plusieurs elements, dont 
les risques, le temps restant dans le cadre du projet et la performance technique. Ce niveau de performance est 
represente par la ligne TCPI (EAC) de I'indice de performance a terminaison du projet (cout final estime). La formule 
de l'indice de performance a terminaison du projet basee sur le cout final estime est: (BAC - EV) / (EAC - AC). Les 
formules de la gestion de la valeur acquise sont indiquees dans le tableau 7-1. 
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Tableau 7-1. Tableau recapitulatif des calculs de la valeur acquise 


Analyse de la valeur acquise 


Abreviation 

Nom 

Definition du lexique 

Utilisation 

Formule 

Interpretation du resultat 

PV 

Valeur 

planifiee 

Le budget autorise alloue au travail 
prevu. 

Valeur du travail planifie a achever 
a un moment donne, souvent 
la date des donnees ou I’achevement 
du projet. 



EV 

Valeur 

acquise 

La mesure du travail effectue 
exprimee en termes de budget 
autorise pour ce travail. 

Valeur planifiee de tout le travail 
acheve (acquise) a un moment 
donne, souvent la date des donnees, 
sans reference aux couts reels. 

Valeur acquise (EV) = somme 
de la valeur planifiee 
du travail acheve 


AC 

Cout reel 

Les couts reels encourus pour le travail 
execute sur une activite, pendant une 
periode de temps specifique. 

Cout reel de tout le travail acheve 
a moment donne, souvent la date 
des donnees. 



BAC 

Budget a 
terminaison 

La somme de tous les budgets 
etablis pour le travail a effectuer. 

Valeur du travail planifie total, 
reference de base des couts du projet. 



CV 

Ecart de cout 

Le montant du deficit ou 
de I’excedent budgetaire a un point 
donne dans le temps, exprime 
comme la difference entre la valeur 
acquise et le cout reel. 

Difference entre la valeur du travail 
acheve a un moment donne, souvent 
la date des donnees, et les couts 
reels au meme moment. 

CV = EV - AC 

Resultat positif = inferieur au cout 
planifie 

Resultat neutre = conforme au cout 
planifie 

Resultat negatif = superieur au cout 
planifie 

S V 

Ecart 
de delais 

La duree d'avance ou de retard 
du projet par rapport a la date 
de livraison planifiee, a un point 
donne dans le temps, exprimee 
comme la difference entre la valeur 
acquise et la valeur planifiee. 

Difference entre la valeur du travail 
acheve a un moment donne, souvent 
la date des donnees, et le travail 
planifie a achever au meme moment. 

SV = EV - PV 

Resultat positif = avance par rapport 
a Techeancier 

Resultat neutre = conforme a 
Techeancier 

Resultat negatif = retard par rapport 
a Techeancier 

VAC 

Ecart 

a terminaison 

Projection du montant du deficit 
ou de I'excedent budgetaire, exprime 
comme la difference entre le budget 
a terminaison et le cout estime 
a terminaison. 

Difference estimee en termes 
de couts a I’achevement du projet. 

VAC = BAC - EAC 

Resultat positif = inferieur au cout 
planifie 

Resultat neutre = conforme au cout 
planifie 

Resultat negatif = superieur au cout 
planifie 

CPI 

Indice de 
performance 
des couts 

Une mesure de rendement du cout 
des ressources budgetisees 
exprimee par le ratio de la valeur 
acquise rapportee au cout reel. 

Un indice de performance des couts 
(CPI) de 1,0 signifie que le projet 
respecte precisement le budget, que 
le travail reellement effectue 
correspond exactement aux couts 
jusqu’a present. D'autres valeurs 
montrent le pourcentage de couts 
superieurs ou inferieurs au budget 
du travail acheve. 

CPI = EV/AC 

Superieur a 1 = inferieur au cout 
planifie 

Exactement 1 = conforme au cout 
planifie 

inferieur a 1 = superieur au cout 
planifie 

SPI 

Indice de 
performance 
des delais 

Mesure de rendement de 

I’echeancier exprimee par le ratio 
de la valeur acquise rapportee 
a la valeur planifiee. 

Un indice de performance des delais 
(SPI) de 1,0 signifie que le projet 
respecte precisement Techeancier, 
que le travail reellement effectue est 
exactement le meme que le travail 
planifie a effectuer jusqu’a present 
D’autres valeurs montrent le 
pourcentage de couts superieurs ou 
inferieurs au budget du travail planifie. 

SPI = EV/PV 

Superieur a 1 = avance par rapport a 
Techeancier 

Exactement 1 = conforme a 
Techeancier 

Inferieur a 1 = retard par rapport a 
Techeancier 

EAC 

Cout estime 
a terminaison 

Lestimation du cout total 
a terminaison de I’ensemble du 
travail, exprime comme la somme 
du cout reel a la date concernee et 
du Reste a faire. 

Si I’indice de performance des couts 
est cense etre le meme pour le reste 
du projet, le cout final estime (EAC) 
peut etre calcule selon les formules 
suivantes: 

EAC = BAC/CPI 





Si le travail futur est accompli 
a la vitesse planifiee: 

EAC = AC + BAC - EV 





Si le plan initial n’est plus valable: 

EAC = AC + ETC a partir 
de la base 





Si le CPI et le SPI influenced le 
travail restant : 

EAC = AC + [(BAC - EV)/ 

(CPI x SPI)] 


RAF 

Cout du reste 
a faire 

Le cout prevu pour terminer tous 
les travaux restants du projet. 

En supposant que le travail s’effectue 
comme prevu, le cout d’execution 
du travail autorise restant peut etre 
calcule comme suit: 

? 

rn 

> 

o 

> 

o 





Re-estimer le travail restant a partir 
de la base. 

ETC = nouvelle estimation 


TCPI 

Indice de 
performance 
a terminaison 
du projet 

Mesure de la performance des couts 
qui doit etre atteinte avec 
les ressources restantes afin 
de satisfaire a un objectif 
de management donne, exprimee 
par le ratio du cout pour terminer 
le travail non acheve par rapport 
au budget restant. 

Lefficacite qui doit etre maintenue 
afin d'executer le plan. 

Lefficacite qui doit etre maintenue 
afin d’atteindre le cout final estime 
actuel. 

TCPI = (BAC-EV)/(BAC-AC) 

TCPI = (BAC - EV)/(EAC-AC) 

Superieur a 1 = plus difficile 
a atteindre 

Exactement 1 = meme niveau 
d’obtention 

Inferieur a 1 = plus facile a atteindre 

Superieur a 1 = plus difficile 
a atteindre 

Exactement 1 = meme niveau 
d'obtention 

Inferieur a 1 = plus facile a atteindre 
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Figure 7-13. Indice de performance a terminaison du projet 


7.4.2.4 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d’information de management du projet (Project Management 
Information Systems, PMISjsont souvent utilises pour suivre les trois dimensions de la gestion de la valeur acquise (a 
savoir la valeur planifiee, la valeur acquise et le cout reel) pour afficher des graphiques de tendance et pour prevoir une 
plage de resultats finaux possibles pour le projet. 


7.4.3 MAITRISER LES COOTS : DONNEES DE SORTIE 

7.4.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L'information sur la performance d’execution comporte des donnees relatives a la 
performance du projet comparee a la reference de base des couts. Les ecarts entre le travail effectue et son cout sont 
evalues au niveau d’un lot de travail et au niveau d’un centre de consolidation. Pour les projets qui utilisent I'analyse 
de la valeur acquise, les ecarts de cout, I’indice de performance des couts, le cout final estime, I’ecart a terminaison 
et I’indice de performance a terminaison du projet sont documents et destines a etre inclus dans les rapports sur la 
performance d'execution (voir la section 4.5.3.1). 
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7.4.3.2 PREVISIONS DES COUTS 


Une valeur calculee ou ascendante du cout final estime est documentee et communiquee aux parties prenantes. 

7.4.3.3 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. L’analyse de la performance du projet peut conduire a une demande de 
changement des references de base des couts et de I’echeancier ou d’autres composants du plan de management du 
projet. Les demandes de changement sont passees en revue et traitees dans le processus MaTtriser les changements 
(voir la section 4.6). 

7.4.3.4 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I’organisation par I’intermediaire d’une demande de changement. Parmi les composants susceptibles de necessiter une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. Les changements du plan de gestion des couts, 
notamment ceux apportes aux seuils de martrise ou aux niveaux indiques d’exactitude requise pour la gestion 
des couts du projet, sont apportes en fonction des remarques des parties prenantes concernees. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference 
de base des couts sont apportes en fonction de I’approbation des changements du perimetre, des ressources 
ou des estimations des couts. Dans certains cas, lorsque les ecarts de cout sonttres importants, une revision de 
la reference de base des couts est necessaire, afin de disposer d’une base realiste de mesure de performance. 

♦ Reference de base de la performance. Elle est decrite a la section 4.2.3.1. Les changements apportes 
a la reference de base de la performance sont apportes en fonction de I'approbation des changements du 
perimetre, de la performance des delais ou des estimations des couts. Dans certains cas, lorsque les ecarts de 
performance sont tres importants, une demande de changement est soumise pour reviser la reference de base 
de la performance, afin de disposer d’une base realiste de mesure de la performance. 
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7.4.3.5 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. La performance des couts indique si la revision des 
hypotheses concernant la productivite des ressources et d’autres facteurs influant sur la performance des couts 
est necessaire. 

♦ Base des estimations. Elle est decrite a la section 6.4.3.2. La performance des couts indique si la revision de la 
base des estimations initiate est necessaire. 

♦ Estimations des couts. Elies sont decrites a la section 7.2.3.1. La mise a jour des estimations des couts peut 
s'averer necessaire afin de refleter I’efficacite du cout reel du projet. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour par I'ajout de techniques qui se sont averees efficaces pour respecter le budget: I'analyse des 
ecarts, I'analyse de la valeur acquise, les previsions ainsi que les actions correctives utilisees pour rattraper les 
ecarts de couts. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques peut etre mis a jour si les ecarts 
de couts ont croise, ou sont susceptibles de croiser, le seuil de cout. 
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GESTION DE LA QUALITE DU PROJET 

La gestion de la qualite du projet inclut les processus de prise en compte de la politique qualite de I’organisation en 
ce qui concerne la planification, la gestion et le controle des exigences de qualite du produit et du projet afin d’atteindre 
les objectifs des parties prenantes. Elle soutient egalement les activites d’amelioration continue des processus menees 
au nom de I'organisation realisatrice. 

Les processus de gestion de la qualite du projet sont les suivants : 

8.1 Planifier la gestion de la qualite —Ce processus consiste a identifier les exigences de qualite et les standards 
a respecter pour le projet et ses livrables, et a documenter comment le projet etablira sa conformite aux exigences et/ 
ou aux standards de qualite. 

8.2 Gerer la qualite —Ce processus consiste a transformer le plan de gestion de la qualite en activites ad hoc qui 
integrent au projet les politiques qualite de I'organisation. 

8.3 Maitriser la qualite —Ce processus consiste a martriser et enregistrer les resultats des activites de gestion de la 
qualite pour evaluer la performance et s’assurer que les produits du projet sont exhaustifs, conformes et satisfont aux 
attentes du client. 

La figure 8-1 presente une vue d’ensemble des processus de gestion de la qualite du projet. Les processus de gestion 
de la qualite du projet sont presentes comme des processus distincts ayant des interfaces clairement definies, alors 
que, dans la pratique, ils s'imbriquent et interagissent de differentes manieres qui ne peuvent pas etre completement 
detaillees dans le Guide PMBOK®. De plus, ces processus de qualite peuvent varier selon le secteur et I’organisation. 
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Vue d’ensemble de la gestion 
de la qualite du projet 


8.1 Planifier 

le management de la qualite 


.1 Donnees d'entree 
.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 
.2 Outils et techniques 

.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Prise de decision 
.5 Representation des donnees 
.6 Planification des tests et 
des inspections 
.7 Reunions 
.3 Donnees de sortie 

.1 Plan de gestion de la qualite 
.2 Metriques qualite 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

V___/ 


8.2 Gerer la qualite 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Actifs organisationnels 
.2 Outils ettechniques 
.1 Collecte des donnees 
.2 Analyse des donnees 
.3 Prise de decision 
.4 Representation des donnees 
.5 Audits 
.6 Design forX 
.7 Resolution de problemes 
.8 Methodes d'amelioration 
de la qualite 
.3 Donnees de sortie 
.1 Rapport de qualite 
.2 Documents devaluation et 
de test 

.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du projet 

V___/ 


8.3 Maitriser la qualite 


.1 Donnees d’entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Demandes de changement 
approuvees 
.4 Livrables 

.5 Donnees de performance 
d'execution 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 
.2 Outils ettechniques 
.1 Collecte des donnees 
.2 Analyse des donnees 
.3 Inspection 

.4 Tests/evaluations du produit 
.5 Representation des donnees 
.6 Reunions 
.3 Donnees de sortie 
.1 Mesures de controle 
de la qualite 
.2 Livrables verifies 
.3 Information sur 

la performance d'execution 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour des documents 
du projet 

v___/ 


Figure 8-1. Vue d’ensemble de ia gestion de la qualite du projet 


La figure 8-2 presente une vue d’ensemble des principales donnees d’entree et de sortie des processus de gestion 
de la qualite du projet et des interrelations des processus dans le domaine de connaissance en gestion de la qualite 
du projet. Le processus Planifier la gestion de la qualite traite de la qualite que le travail necessite. Le processus 
Gerer la qualite est axe sur la gestion des processus de qualite tout au long du projet. Dans le cadre du processus 
Gerer la qualite, les exigences de qualite identifies lors du processus Planifier la gestion de la qualite deviennent des 
instruments devaluation et de test. Ces derniers sont ensuite appliques pendant le processus Maitriser la qualite afin 
de verifier que le projet repond aux exigences de qualite. Le processus Maitriser la qualite compare les resultats du 
travail aux exigences de qualite afin de s’assurer que le resultat est acceptable. Deux donnees de sortie specifiques 
au domaine de connaissance en gestion de la qualite du projet sont utilisees par d’autres domaines de connaissance, 
a savoir les livrables verifies et les rapports de qualite. 
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de la qualite 


Metriques qualite 


Gerer 

Rapports qualite 

Vers d’autres 



la qualite 

◄- 


processus 
du projet 


Documents d'evaluation 
et de test 


Mesures de controle 
de la qualite 


Gestion 
de (’integration 
du projet 


Rapports qualite 


Livrables 

Donnees de performance d’execution 


Mattriser 
la qualite 





Livrables verifies 


Information sur la performance 
d'execution 
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Figure 8-2. Principales interrelations des processus de gestion de la qualite du projet 


PRINCIPAUX CONCEPTS DE LA GESTION DE LA OUALITE DU PROJET 

La gestion de la qualite du projet porte a la fois sur le management du projet et sur ses livrables. II s’applique 
a tous les projets, independamment de la nature de leurs livrables. Les mesures et les techniques relatives a la 
qualite sont specifiques au type de livrables generes par le projet. Par exemple, la gestion de la qualite des livrables 
du secteur informatique implique des approches et des mesures differentes de celles utilisees pour construire une 
centrale nucleaire. Dans un cas comme dans I’autre, le non-respect des exigences de qualite peut entraTner des 
consequences negatives graves pour les parties prenantes du projet. Par exemple : 

♦ satisfaire aux exigences du client par un surmenage de I’equipe projet peut conduire a une diminution des profits 
et un accroissement des niveaux de risques globaux du projet, a des demissions, a des erreurs ou a des reprises; 

♦ respecter les objectifs de I’echeancier du projet, en effectual a la hate les inspections qualite planifiees, peut 
compromettre la detection d’erreurs, entraTner une diminution des profits et accroTtre les risques ulterieurs lors 
de I’utilisation du produit. 
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Qualite et classe sont deux notions differentes. La qualite, en tant que performance ou resultat livre, est«le degre 
auquel un ensemble de caracteristiques intrinseques satisfait a des exigences »(ISO 9000) [18]. La classe, en tant 
qu’intention de conception, est une categorie attribute aux livrables ayant la meme utilisation fonctionnelle, mais des 
caracteristiques techniques differentes. Le chef de projet et I’equipe de management de projet sont responsables des 
arbitrages quant a la livraison des niveaux requis en matiere de qualite et de classe. Alors qu’un niveau de qualite 
ne satisfaisant pas aux exigences de qualite est toujours un probleme, un produit de classe inferieure ne I'est pas 
necessairement. Par exemple: 

♦ un produit convenable de classe inferieure (offrant un nombre limite de fonctionnalites) et de haute qualite (sans 
defauts evidents) ne represente pas necessairement de probleme. Dans cet exemple, le produit serait adequat 
pour I’usage general auquel il est destine. 

♦ En revanche, un produit de classe superieure (offrant de nombreuses fonctionnalites) et de qualite mediocre (de 
nombreux defauts) peut constituer un probleme. Fondamentalement, un produit de classe elevee peut s'averer 
inoperant et/ou inefficace en raison de safaible qualite. 

La prevention est preferable a I’inspection. II vaut mieux integrer la qualite dans la conception des livrables que 
d’identifier des problemes de qualite lors de I'inspection. Le cout de la prevention des erreurs est generalement bien 
inferieur au cout de leur correction lorsqu’elles sont detectees par une inspection ou en cours d’utilisation. 

En fonction du projet et du secteur industriel, I'equipe projet peut avoir besoin d’une connaissance pratique des 
processus de controle statistique de fagon a pouvoir evaluer les donnees de sortie de la maTtrise de la qualite. L’equipe 
doit connaTtre les differences entre les paires de notions suivantes : 

♦ prevention (eviter les erreurs dans les processus) et inspection (eviter que les erreurs ne surviennent chez le client); 

♦ echantillonnage par attributs (le resultat est soit conforme, soit non conforme) et echantillonnage par variables 
(le resultat est indique sur une echelle continue qui mesure le degre de conformite); 

♦ tolerances (fourchette de resultats acceptables) et seuils de controle (qui identifient les limites de variance 
commune dans un processus ou dans la performance d’un processus statistiquement stable). 

Le cout de la qualite (Cost of Quality, COQ) inclut tous les couts relatifs a la qualite au cours de la vie du produit: 
les couts d’investissement dans la prevention des non-conformites aux exigences, les couts devaluation du produit 
ou du service pour s’assurer de sa conformite aux exigences et les couts de reprises dues au non-respect de ces 
exigences. Les couts des defauts sont souvent categorises en interne (lorsqu’ils sont constates par I’equipe projet) et 
externe (lorsqu’ils sont constates par le client). Les couts des defauts sont egalement appeles cout de la non-qualite. 
La section 8.1.2.3 donne quelques exemples a prendre en compte pour chacune de ces categories. Les organisations 
choisissent d’investir dans la prevention des defauts en raison des avantages qu’elle procure au cours de la vie du 
produit. Les projets etant par nature temporaires, les decisions sur le cout de la qualite au cours du cycle de vie d’un 
produit relevent souvent du management de programme, du management de portefeuille, du bureau des projets (Project 
Management Office, PMO) ou des operations. 
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II existe cinq niveaux d’efficacite croissante en matiere de gestion de la qualite. 

♦ En general, I’approche la plus couteuse consiste a laisser le client decouvrir les defauts. Cette approche 
s'accompagne de problemes de garantie, de rappels, de perte de reputation et de couts de reprise. 

♦ Dans le cadre du processus MaTtriser la qualite, il convient de detecter et de corriger les defauts avant d’envoyer 
les livrables au client. Le processus MaTtriser la qualite comporte des couts connexes qui sont principalement des 
couts devaluation et de defaillances internes. 

♦ L’assurance qualite permet d’examiner et de corriger le processus, pas seulement des defauts en particulier. 

♦ Pour cela, la qualite doit faire partie integrante de la planification et de la conception du projet et du produit. 

♦ Enfin, il convient d’insuffler une culture de qualite des processus et des produits au sein de ^organisation. 

TENDANCES ET PRATIQUES EMERGENTES EN GESTION DE LA QUALITE DU PROJET 

Les approches modernes de la gestion de la qualite visent a reduire les variations et a fournir des resultats qui 
repondent aux exigences des parties prenantes. Les tendances de la gestion de la qualite du projet comprennent 
notamment les elements suivants : 

♦ Satisfaction du client. Comprendre, evaluer, definir et gerer les exigences afin de satisfaire aux attentes du 
client. Cela implique la conformite aux exigences (de fagon a ce que le projet produise ce pour quoi il a ete 
entrepris) et I'aptitude a I'emploi (de sorte que le produit ou le service satisfasse aux besoins reels). Dans les 
environnements agiles, I’engagement des parties prenantes avec I'equipe permet d’assurer que la satisfaction 
du client est maintenue tout au long du projet. 

♦ Amelioration continue. Le cycle Planifier-Derouler-Controler-Agir (Plan-Do-Check-Act, PDCA) est la base de 
I’amelioration de la qualite (suivant la definition de Shewhart, modifiee par Deming). De plus, les demarches 
d’amelioration de la qualite, telles que la gestion de la qualite totale (Total Quality Management, TQM), I'approche 
Six Sigma ou Lean Six Sigma, peuvent ameliorer aussi bien la qualite du management de projet que la qualite du 
produit fini, du service ou du resultat du projet. 

♦ Responsabilite du management. Le succes requiert la participation de tous les membres de I’equipe projet. Le 
management assume, dans le cadre de sa responsabilite vis-a-vis de la qualite, la responsabilite de fournir les 
ressources appropriees en quantite suffisante. 

♦ Partenariat d’interet mutuel avec les fournisseurs. Organisation et fournisseurs sont interdependants. Les 
relations fondees sur le partenariat et la cooperation avec le fournisseur sont plus avantageuses pour les deux 
parties qu'une gestion des fournisseurs traditionnelle. L'organisation doit privilegier les relations a long terme 
plutot que les gains a court terme. Une relation mutuellement benefique ameliore la capacite de l'organisation 
et des fournisseurs a creer de la valeur reciproque, la reponse commune aux besoins et aux attentes du client et 
optimise les couts et les ressources. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 

Chaque projet etant unique, le chef de projet devra adapter la maniere dont les processus de gestion de la qualite du 
projet sont appliques. Parmi les considerations relatives a I’adaptation, on peut citer les elements suivants : 

♦ Respect des politiques et audit. Quelles politiques et procedures qualite I’organisation a-t-elle mises en place ? 
Quels outils, techniques et modeles de qualite I’organisation utilise-t-elle ? 

♦ Respect des normes et des regimentations. Des normes de qualite specifiques du secteur doivent-ils etre 
appliquees ? Des contraintes reglementaires, juridiques ou gouvernementales specifiques doivent-elles etre 
prises en compte ? 

♦ Amelioration continue. Comment I’amelioration de la qualite est-elle geree dans le projet ? Est-elle geree au 
niveau de I’organisation ou au niveau de chaque projet ? 

♦ Engagement des parties prenantes. Les parties prenantes et les fournisseurs beneficient-ils d’un environnement 
collaboratif ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Pour gerer les changements, les methodes agiles necessitent que les etapes de revue et de qualite soient integrees 
frequemment et tout au long du projet plutot que concentrees a la fin du projet. 

Les revues retrospectives recurrentes permettent de verifier regulierement I’efficacite des processus de qualite. Elies 
recherchent la cause originelle des points a traiter puis proposent d’essayer de nouvelles approches pour ameliorer la 
qualite. Les revues retrospectives suivantes evaluent les processus d’essai afin de determiner si elles fonctionnent et 
doivent etre maintenues, necessiter des ajustements ou etre abandonnees. 

En vue de faciliter la livraison progressive et frequente, les methodes agiles se concentrent sur les petits lots de 
travail, en integrant autant d’elements livrables du projet que possible. Les systemes de petit lot (small batch) ont 
pour but de reveler les incoherences et les problemes de qualite tot dans le cycle de vie du projet, lorsque les couts du 
changement sont moindres. 
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8.1 PLANIFIER LA GESTION DE LA QUALITE 


Planifier la gestion de la qualite est le processus qui consiste a identifier les exigences et/ou les normes de qualite a 
suivre pour le projet et ses livrables, et a documenter comment sera demontree la conformite a ces exigences et/ou les 
normes de qualite. L’interet principal de ce processus est qu'il fournit les directives et les orientations sur la fagon dont 
la qualite sera geree et verifiee tout au long du projet. Ce processus est execute une fois ou a des moments predefinis 
du projet. Les donnees d’entree et de sortie de ce processus sont presentees a la figure 8.3. La figure 8.4 represente le 
diagramme de flux de donnees de ce processus. 


Planifier la gestion de la qualite 


Donnees d’entree H Outils et techniques ■ Donnees de sortie 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion 
des exigences 

• Plan de gestion des risques 

• Plan d'engagement 
des parties prenantes 

• Reference de base 
du perimetre 

.3 Documents du projet 

• Journal des hypotheses 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

• Registre des risques 

• Registre des parties 
prenantes 

.4 Facteurs environnementaux 

de I'organisation 
.5 Actifs organisationnels 

v___y 


.1 Jugement a dire d'expert 
.2 Collecte des donnees 

• Benchmarking 

• Brainstorming 

• Entretiens 

.3 Analyse des donnees 

• Analyse cout-benefice 

• Cout de la qualite 
.4 Prise de decision 

• Analyse decisionnelle 
multicritere 

.5 Representation des donnees 

• Diagrammes de flux 

• Modele logique de donnees 

• Diagrammes matriciels 

• Mind maps 

.6 Planification des tests et 
des inspections 
.7 Reunions 

V_/ 


.1 Plan de gestion de la qualite 
.2 Metriques qualite 
.3 Mises a jour du plan 

de management du projet 

• Plan de gestion des risques 

• Reference de base 
du perimetre 

.4 Mises a jour des documents 

du projet 

• Registre des retours 
d'experience 

• Matrice de tragabilite 
des exigences 

• Registre des risques 

• Registre des parties 
prenantes 

-y 


Figure 8-3. Planifier la gestion de la qualite: donnees d’entree, outils, techniques et donnees de sortie 


277 














4.1 

Elaborer 
la charte 
du projet 


Charte du projet 


Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion des exigences 

• Plan de gestion des risques 

• Plan d’engagement 
des parties prenantes 

• Reference de base du perimetre 


Documents 
du projet 


Documents du projet 

• Journal des hypotheses 

• Documentation des exigences 

• Matrice de tragabilite des exigences 

• Registre des risques 

• Registre des parties prenantes 


Entreprise/ 

Organisation 


Plan de gestion de la qualite 


8.1 

Planifier 
la gestion 
de la qualite 



Metriques qualite 


Documents 
du projet 


Mises a jour des documents du projet 

• Registre des retours d’experience 

• Matrice de tragabilite des exigences 

• Registre des risques 

• Registre des parties prenantes 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 8-4. Planifier la gestion de la qualite: diagramme de flux de donnees 


La planification de la qualite doit etre effectuee en parallele avec les autres processus de planification. Par exemple, 
les propositions de changement a apporter aux livrables pour les rendre conformes aux normes de qualite, peuvent 
necessiter des ajustements du cout ou de I'echeancier et une analyse des risques detaillee des impacts sur les plans. 

Les techniques de planification de la qualite discutees dans cette section sont le plus frequemment utilisees dans 
les projets. II en existe beaucoup d’autres qui peuvent etre utiles pour certains projets ou dans certains domaines 
d’application. 
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8.1.1 PLANIFIER LA GESTION DE LA QUALITE : DONNEES D’ENTREE 


8.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet donne une description generate du projet et des caracteristiques 
du produit. Elle contient egalement les exigences d’approbation du projet, les objectifs mesurables du projet et les 
criteres de succes qui influenceront la gestion de la qualite du projet. 

8.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences fournit 
une approche pour identifier, analyser et gerer les exigences auxquelles le plan de gestion de la qualite et les 
metriques qualite feront reference. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques fournit une 
approche pour identifier, analyser et maTtriser les risques. Les informations des plans de gestion des risques et 
de gestion de la qualite contribuent ensemble a garantir la reussite du projet et du produit. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d'engagement des parties 
prenantes indique la methode pour documenter les besoins et les attentes des parties prenantes afin de fournir 
les fondements de la gestion de la qualite. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Le WBS et les livrables consignes dans 
renonce du perimetre du projet sont pris en compte afin d’identifier quels normes et objectifs de qualite sont 
appropries pour le projet, et quels livrables et processus du projet qui feront I’objet d'une revue de la qualite. 
L'enonce du perimetre indique les criteres d’acceptation pour les livrables. La definition des criteres d’acceptation 
peut augmenter ou reduire de maniere significative le cout de la qualite et, par consequent, celui du projet. 
Satisfaire a tous les criteres d’acceptation implique d’avoir repondu aux besoins des parties prenantes. 
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8.1.1.3 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses contient toutes les 
hypotheses et les contraintes concernant le respect des normes et des exigences de qualite. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences decrit les 
exigences auxquelles le projet et le produit doivent satisfaire pour repondre aux attentes des parties prenantes. 
Parmi les composants de la documentation des exigences figurent notamment les exigences de qualite du projet 
et du produit. L’equipe projet s'appuie sur ces exigences pour planifier comment la martrise de la qualite est 
appliquee au niveau du projet. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
relie les exigences du produit aux livrables. Elle aide a garantir que toutes les exigences contenues dans la 
documentation des exigences sont testees. Cette matrice donne une vue d’ensemble des tests necessaires a la 
verification des exigences. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques comporte des informations 
relatives aux menaces et aux opportunity qui peuvent avoir un impact sur les exigences de qualite. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes permet 
d'identifier les parties prenantes ayant un interet particulier ou une incidence sur la qualite. II porte une attention 
particuliere aux besoins et aux attentes du client et du sponsor du projet. 

8.1.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion de la qualite, on peut citer: 

♦ les regimentations d’agences gouvernementales; 

♦ les regies, les normes et les directives specifiques a un domaine d'application ; 

♦ la repartition geographique ; 

♦ la structure organisationnelle; 

♦ les conditions du marche ; 

♦ les conditions de travail du projet ou les conditions operationnelles du projet, ou de ses livrables; 

♦ les perceptions culturelles. 
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8.1.1.5 ACTIFS ORGANISATION ELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion de la qualite, 
on peut citer: 

♦ le systeme de gestion de la qualite de I'organisation, y compris les politiques, les procedures et les directives ; 

♦ les modeles de qualite, tels que les fiches de controle et la matrice de tragabilite ; 

♦ les bases de donnees historiques et les archives des retours d’experiences. 

8.1.2 PLANIFIER LA GESTION DE LA QUALITE : OUTILS ET TECHNIQUES 

8.1.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II taut considerer I’expertise d’individus ou de groupes ayant une connaissance 
specialist ou une formation dans les domaines suivants: 

♦ I’assurance qualite; 

♦ la martrise de la qualite; 

♦ les mesures de la qualite; 

♦ les ameliorations de la qualite ; 

♦ les systemesde qualite. 

8.1.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Benchmarking. Le benchmarking consiste a comparer les standards de qualite ou les pratiques du projet, 
reelles ou planifiees, avec celles de projets comparables, dans le but d’identifier les meilleures pratiques, de 
trouver des idees d’ameliorations et de fournir une base pour la mesure de performance. Les projets ayant fait 
I’objet d’une etude comparative peuvent provenir de I’organisation realisatrice ou non, ou appartenir au meme 
domaine d’application ou non. Le benchmarking permet d’effectuer des analogies a partir de projets appartenant 
a un autre domaine d’application ou secteur. 

♦ Brainstorming. II est decrit a la section 4.1.2.2. Le brainstorming permet de collecter des donnees de maniere 
creative aupres d’un groupe de membres de I'equipe ou d'experts du domaine concerne en vue d’elaborer le plan 
de gestion de la qualite qui correspond le mieux au nouveau projet. 
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♦ Entretiens. Ms sont decrits a la section 5.2.2.2. Qu’ils soient implicites ou explicites, formels ou informels, les 
besoins et les attentes en matiere de qualite du projet et du produit peuvent etre identifies en interrogeant les 
participants au projet, les parties prenantes et les experts dans le domaine concerne. Les entretiens doivent 
avoir lieu dans un climat de confiance et dans le respect de la confidentiality afin d’encourager les contributions 
honnetes et impartiales. 

8.1.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse cout-benefice. L’analyse cout-benefice est un outil d’analyse financiere utilise pour evaluer les forces 
et faiblesses des alternatives afin d’identifier la meilleure alternative. De plus, elle permet au chef de projet de 
determiner si les activites de qualite planifiees sont rentables. Les avantages principaux de la satisfaction aux 
exigences de qualite sont, notamment, une diminution des reprises, une plus grande productivite, une reduction 
des couts, un degre de satisfaction accru de la part des parties prenantes et une meilleure rentabilite. Une 
analyse cout-benefice de chacune des activites qualite permet d’evaluer le cout d’une demarche qualite en 
comparaison de I’avantage attendu. 

♦ Cout de la qualite. Le cout de la qualite (cost of quality, COQ) associe a un projet comprend au moins un des 
couts suivants. (La figure 8-5 liste des exemples pour chaque groupe de couts.) 

■ Couts de prevention. II s’agit des couts induits par la prevention de la qualite mediocre des produits, des 
livrables ou des services d’un projet donne. 

■ Couts devaluation. II s’agit des couts induits par revaluation, la mesure, I’audit et le test des produits, des 
livrables ou des services d’un projet donne. 

■ Couts des defauts (internes/externes). II s’agit des couts induits par les produits, livrables ou services qui sont 
non conformes et done ne satisfont pas les besoins ou attentes des parties prenantes. 

Le cout de la qualite optimal est celui qui reflete un equilibre approprie entre, d’une part, I’investissement des 
couts de preventions et devaluation et, d’autre part, les couts de defauts que cet investissement permet d’eviter. 
Des modeles demontrent qu’il existe un cout de la qualite optimal pour les projets, ou I’investissement dans des 
couts de prevention/d’evaluation supplemental n’est ni benefique ni rentable. 
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Cout de conformite Cout de non-conformite 


Couts des defaillances internes 

(Defaillances constatees par le projet) 

• Reprise 

• Dechets 

Couts des defaillances externes 

(Defaillances constatees par le client) 

• Responsabilites 

• Travail sous garantie 

• Affaire perdue 


Argent depense pendant et apres 
le projet a cause des defaillances 

Argent depense au cours du projet 

pour eviter les defaillances 


Couts de prevention 

(Fabriquer un produit de qualite) 

• Formation 

• Processus documentaires 

• Equipement 

• Delai approprie 

Couts devaluation 

(Evaluer la qualite) 

• Tests 

• Perte liee a des tests destructifs 

• Inspections 


Figure 8-5. Cout de la qualite 


8.1.2.4 PRISE DE DECISION 

Parmi les techniques de prise de decision pouvant etre utilisees dans le cadre de ce processus figure notamment 
I'analyse decisionnelle multicritere. Les outils d'analyse decisionnelle multicritere (par exemple, la matrice des priorites) 
permettent d'identifier les principaux points a traiter et les solutions alternatives a hierarchiser comme un ensemble de 
decisions a appliquer. Les criteres sont hierarchises et ponderes avant d’etre appliques a toutes les options disponibles, 
afin d’obtenir un score pour classer chacune des alternatives. Dans le cadre de ce processus, ils permettent de 
hierarchiser les metriques qualite. 
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8.1.2.5 REPRESENTATION DES DONNEES 


Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Diagrammes de flux. Les diagrammes de flux, aussi appeles cartographies des processus, presented la serie 
d’etapes et les diverses possibility liees a un processus qui transforme des donnees d’entree en donnees de 
sortie. Les diagrammes de flux presentent les activites, les points de decision, les boucles de branchement, 
les chemins parallels, ainsi que I’ordre general d’execution, en cartographiant les details operationnels des 
procedures d’une chame de valeur. La figure 8-6 montre une version de charne de valeur, le modele SIPOC 
(suppliers, inputs, process, outputs, and customers ou fournisseurs, donnees d’entree, processus, donnees de 
sortie et clients). Ce type de diagramme permet de comprendre et d'estimer le cout de la qualite d’un processus. 
La logique de branchement des flux de travaux («workflow») et les frequences relatives associees permettront 
d’estimer la valeur monetaire attendue des efforts de mise en conformite et des travaux dus a la non-conformite 
necessaires pour fournir les donnees de sortie conformes. Lorsque les diagrammes de flux represented les 
etapes d’un processus, ils sont parfois appeles processus de flux ou diagrammes de flux des processus. Ils 
permettent d’ameliorer les processus, d’identifier les defauts de qualite potentiels ou de savoir ou mettre les 
points de controles qualite. 

♦ Modele logique de donnees. Les modeles logiques de donnees sont une representation visuelle des donnees 
d’une organisation, decrite dans le jargon des affaires et independante de toute technologie. Ils sont utilises pour 
identifier ou des problemes d'integrite de donnees ou de qualite peuvent se produire. 

♦ Diagrammes matriciels. Les diagrammes matriciels aident a trouver la force des relations entre differents 
facteurs, causes et objectifs qui existent entre les lignes et les colonnes qui torment la matrice. Le chef de projet 
peut utiliser differentes formes de diagrammes matriciels en fonction du nombre de facteurs a comparer, par 
exemple, L, T, Y, X, C et en forme de pyramide. Dans ce processus, ces diagrammes facilitent I’identification des 
principales metriques qualite qui sont importantes pour la reussite du projet. 

♦ Mind maps. II est decrit a la section 5.2.2.3. Les Mind maps permettent d’organiser les informations de maniere 
visuelle. Dans le domaine de la qualite, elles sont souvent creees autour d’un seul concept, comme un dessin au 
centre d’une page blanche, auquel sont ajoutees des representations associees d’idees, telles que des images, 
des mots et des parties de mots. La technique des mind maps peut aider a reunir rapidement les exigences de 
qualite, les contraintes, les dependences et les relations du projet. 
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Fournisseurs Donnees d'entree Processus Donnees de sortie Clients 



Liste des exigences Liste des mesures Liste des exigences Liste des mesures 


REMARQUE: les elements de ce diagramme sont flexibles et peuvent prendre n’importe quelle direction en fonction des circonstances. 


Figure 8-6. Modele SIPOC 


8.1.2.6 PLANIFICATION DES TESTS ET DES INSPECTIONS 

Lors de la phase de planification, le chef de projet et I'equipe projet s’accordent sur les moyens pour tester ou 
inspecter le produit, le livrable ou le service afin de satisfaire aux besoins et aux attentes des parties prenantes mais 
aussi en vue d’atteindre I’objectif de performance et de fiabilite du produit. Les tests et les inspections dependent 
du secteur. II peut s'agir, par exemple, des tests alpha et beta pour les projets de logiciels, des tests de resistance 
pour les projets de construction, de I’inspection pour la fabrication et des tests de terrain mais aussi des tests non 
destructifs pour I’ingenierie. 
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8.1.2.7 REUNIONS 


Les equipes projet tiennent des reunions de planification dans le but d’elaborer le plan de gestion de la qualite. 
Les participants peuvent inclure le chef de projet, le sponsor du projet, des membres selectionnes de I'equipe projet, 
d’autres parties prenantes choisies, toute personne ayant la responsabilite d’activites de gestion de la qualite du projet, 
ainsi que d’autres personnes, en fonction des besoins. 


8.1.3 PLANIFIER LA GESTION DE LA QUALITE : DONNEES DE SORTIE 
8.1.3.1 PLAN DE GESTION DE LA QUALITE 

Le plan de gestion de la qualite est une composante du plan de management du projet qui decrit la maniere dont 
les directives, les procedures et les politiques applicables seront appliquees pour atteindre les objectifs relatifs a la 
qualite. II detaille egalement les activites et les ressources necessaires a I’equipe de management de projet pour 
atteindre ces objectifs de qualite fixes pour le projet. Le plan de gestion de la qualite peut etre formel ou informel, 
detaille ou formule de maniere generate. Son style et les details qu’il contient sont determines par les exigences du 
projet. Le plan de gestion de la qualite doit etre revu des le debut du projet de fagon a s’assurer que les decisions 
sont basees sur des informations exactes. Les avantages de cette revue peuvent etre, entre autres, un recentrage sur 
la proposition de valeur du projet, une reduction des couts et des depassements de I'echeancier dus a des reprises 
moins frequentes. 

Le plan de gestion de la qualite inclut notamment: 

♦ les standards de qualite utilises pour le projet; 

♦ les objectifs de qualite du projet; 

♦ les roles et les responsabilites en matiere de qualite ; 

♦ les livrables et les processus du projet faisant I’objet d’une revue de la qualite; 

♦ les activites de gestion et de martrise de la qualite planifiees pour le projet; 

♦ les outils de qualite qui seront utilises pour le projet; 

♦ les principales procedures relatives au projet, comme la resolution des non-conformites, les procedures liees aux 
actions correctives et les procedures d’amelioration continue. 
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8.1.3.2 METRIQUES QUALITE 


Une metrique qualite decrit, en termes specifiques, un attribut du projet ou du produit, et la fagon dont le processus 
MaTtriser la qualite en verifiera la conformite. Parmi les exemples de metriques qualite figurent le pourcentage des 
taches executees a temps, la performance des couts mesuree par le CPI, le taux de pannes, le nombre de defauts 
identifies par jour, le temps d’arret (downtime) total par mois, les erreurs detectees par ligne de code, les notes de 
satisfaction des clients et le pourcentage des exigences couvertes par le plan des tests comme mesure de couverture 
des tests. 

8.1. 3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1 . Les decisions relatives a I'approche de gestion 
de la qualite peuvent necessiter des changements de I’approche convenue afin de gerer les risques du projet. 
Ceux-ci seront consignes dans le plan de gestion des risques. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre 
peut changer suite a ce processus si des activites de gestion de la qualite specifiques doivent etre ajoutees. Le 
dictionnaire du WBS, qui consigne egalement les exigences de qualite, peut necessiter une mise a jour. 

8.1. 3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experiences. II est decrit a la section 4.4.3.1. Le registre des retours d’experiences 
est mis a jour a I’aide des informations sur les difficulty rencontrees au cours du processus Planifier la qualite. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. Les exigences de qualite sont 
consignees dans la matrice de tragabilite des exigences lorsqu’elles sont specifies par ce processus. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Lorsque d'autres informations sur les parties 
prenantes (existantes ou nouvelles) sont collectees a I’issue de ce processus, elles sont consignees dans le 
registre des parties prenantes. 
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8.2 GERER LA QUALITE 


Gerer la qualite est le processus qui consiste a transformer le plan de gestion de la qualite en activites ad hoc tout 
en integrant au projet les politiques qualite de I’organisation. L’interet principal de ce processus est qu’il augmente les 
chances d’atteindre les objectifs en termes de qualite et d’identifier les processus inefficaces et les causes de qualite 
mediocre. Le processus Gerer la qualite se sert des donnees et des resultats du processus MaTtriser la qualite afin de 
presenter le statut de la qualite generate du projet aux parties prenantes. Ce processus est execute tout au long du projet. 

Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 8-7. 
La figure 8-8 represente le diagramme de flux de donnees de ce processus. 




1 Plan de management du projet 
• Plan de gestion de la qualite 


.1 Collecte des donnees 


.1 Rapport de qualite 
.2 Documents devaluation 


.2 Documents du projet 
• Registre des retours 


• Checklists 
.2 Analyse des donnees 


et de test 

.3 Demandes de changement 
.4 Mises a jour du plan 


de la qualite 

• Metriques qualite 

• Rapport sur les risques 


d'experience 
• Mesures de controle 


• Analyse des alternatives 

• Analyse des documents 

• Analyse des processus 

• Analyse des causes 


de management du projet 

• Plan de gestion de la qualite 

• Reference de base 


fondamentales 
.3 Prise de decision 


du perimetre 
• Reference de base 


.3 Actifs organisationnels 


• Analyse decisionnelle 


multicritere 


de I'echeancier 
• Reference de base 


.4 Representation des donnees 


• Diagrammes d'affinite 

• Diagrammes cause-effet 

• Diagrammes de flux 

• Histogrammes 

• Diagrammes matriciels 


des couts 

.5 Mises a jour des documents 


du pro jet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Registre des risques 


• Diagrammes de correlation 
.5 Audits 
.6 Design for X 
.7 Resolution de problemes 
.8 Methodes d'amelioration 


de la qualite 


Figure 8-7. Gerer la qualite: donnees d’entree, outils, techniques et donnees de sortie 
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• Demandes de changement 




4.6 

Effectuer 

la gestion integree 
des changements 


Plan 

de management 
du projet 



Plan de management du projet 
• Plan de gestion de la qualite 


Documents 
du projet 



Documents du projet 

• Registre des retours d’experience 

• Mesures de controle de la qualite 

• Metriques qualite 

• Rapport sur les risques 


Entreprise/ 

Organisation 


Mises a jour du plan de management 
du projet 

• Plan de gestion de la qualite 

• Reference de base du perimetre 

• Reference de base de I’echeancier 

• Reference de base des couts 


Plan 

de management 
du projet 


8.2 
Gerer 
la qualite 


Rapport de qualite 
Documents 
devaluation et 
de test 


Documents 
du projet 


Mises a jour des documents du projet 

• Journal des points a traiter 

• Registre des retours d’experience 

• Registre des risques 


• Actifs organisationnels 


Figure 8-8. Gerer la qualite: diagramme de flux de donnees 


Le processus Gerer la qualite est parfois appele Assurance qualite, bien que sa definition soit plus large, car il est 
utilise hors projet. Dans le cadre du management de projet, I’assurance qualite se focalise sur les processus utilises 
dans le projet. L’assurance qualite consiste a se servir des processus de projet de maniere efficace. Elle implique le 
respect des standards afin de garantir que le produit final satisfait aux besoins, aux attentes et aux exigences des 
parties prenantes. Le processus Gerer la qualite incluttoutes les activites d’assurance qualite. II concerne egalement les 
aspects lies a la conception de produit et les ameliorations des processus. Les activites de gestion de la qualite relevent 
de la categorie de la mise en conformite dans le cadre du cout de la qualite. 
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Le processus Gerer la qualite applique un ensemble d’activites et de processus, planifies et systematiques, defini 
dans le plan de gestion de la qualite du projet, de fagon a: 

♦ concevoir un produit optimal et mature grace a I'application de directives specifiques de conception concernant 
certains aspects du produit; 

♦ avoir la certitude que de futures donnees de sortie seront achevees de maniere a satisfaire aux exigences et 
aux attentes specifiques au moyen d’outils et de techniques d’assurance qualite, comme les audits qualite et 
I’analyse des defaillances; 

♦ confirmer que les processus de qualite sont utilises, et que leurs usages correspondent aux objectifs de qualite 
du projet; 

♦ ameliorer I'efficacite et I’efficience des processus et des activites en vue d’obtenir de meilleurs resultats et de 
meilleures performances, et egalement d’ameliorer la satisfaction des parties prenantes. 

Le chef de projet et I’equipe projet peuvent faire appel au departement qualite de I’organisation, ou a d’autres 
fonctions organisationnelles, afin de faire realiser certaines activites de gestion de la qualite, comme I’analyse des 
defaillances, la conception des plans d’experiences (design of experiments) et I'amelioration de la qualite. En regie 
generate, le departement qualite possede une experience intersectorielle de I’utilisation des outils et des techniques de 
qualite et est une ressource utile au projet. 

La gestion de la qualite est I’engagement de tous, a savoir le chef de projet, I’equipe projet, le sponsor du projet, le 
management de I'organisation realisatrice et meme le client. Ms onttous un role a jouer dans la gestion de la qualite du 
projet, meme si I'ampleur et les efforts a fournir peuvent etre differents. Le niveau de participation a I’effort de gestion 
de la qualite peut varier selon le secteur et les styles de management de projet. Dans le cas des projets agiles, la gestion 
de la qualite est assuree tout au long du projet par tous les membres de I’equipe, ce qui n’est pas le cas des projets 
traditionnels ou seuls certains membres de I'equipe sont charges de la gestion de la qualite. 


8.2.1 GERER LA QUALITE : DONNEES D’ENTREE 

8.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le 
plan de gestion de la qualite. Ce dernier, decrit a la section 8.1.3.1, definit le niveau acceptable de qualite du projet et 
de qualite du produit et indique comment garantir ce niveau de qualite pour les livrables et les processus. II precise 
egalement comment proceder avec les produits non conformes et I’action corrective qu’il convient de mettre en oeuvre. 
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8.2.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experiences. II est decrit a la section 4.4.3.1. Les retours d’experiences du debut du 
projet, relatifs a la gestion de la qualite, peuvent etre appliques aux phases ulterieures afin d’ameliorer I’efficacite 
de la gestion de la qualite. 

♦ Mesures de maitrise de la qualite. Elies sont decrites a la section 8.3.3.1. Les mesures de martrise de la qualite 
permettent d’analyser et d’evaluer la qualite des processus et des livrables du projet par rapport aux standards 
de I’organisation realisatrice ou des exigences specifies. Elies permettent egalement de comparer les processus 
employes pour etablir et valider des mesures afin de determiner leur niveau de justesse. 

♦ Metriques qualite. Elies sont decrites a la section 8.1.3.2. Les metriques qualite sont verifiees dans le cadre 
du processus MaTtriser la qualite. Ce processus utilise les metriques qualite comme base pour I'elaboration de 
scenarios de test du projet et de ses livrables, et comme base pour les demarches d’amelioration. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques est utilise dans le cadre du 
processus Gerer la qualite pour identifier les sources du risque global du projet et les facteurs les plus importants 
de I'exposition globale aux risques qui sont susceptibles d'influencer les objectifs de qualite du projet. 

8.2.1.3 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Gerer la qualite, on peut citer: 

♦ le systeme de gestion de la qualite de I’organisation comprenant les politiques, les procedures et les directives; 

♦ les modeles de qualite, tels que les fiches de controle, la matrice de tragabilite mais aussi les plans et documents 
des tests; 

♦ les resultats de precedents audits ; 

♦ I’archive des retours d’experiences avec des informations provenant de projets similaires. 
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8.2.2 GERER LA QUALITE : OUTILS ET TECHNIQUES 


8.2.2.1 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees dans le cadre de ce processus figurent notamment 
les checklists (voir la section 11.2.2.2). Une checklist est un outil structure, habituellement specifique a un composant, 
utilise pour verifier qu’un ensemble d’etapes requises a bien ete execute ou pour verifier qu’une liste d’exigences a ete 
satisfaite. Les checklists peuvent etre simples ou complexes, selon les exigences et les pratiques du projet. Beaucoup 
d’organisations ont des checklists standardises a disposition pour assurer la coherence des taches frequemment 
executees. Dans certains domaines d’application, les checklists sont egalement disponibles aupres dissociations 
professionnelles ou de fournisseurs de services commerciaux. Les checklists de la qualite doivent comporter les criteres 
d’acceptation inclus dans la reference de base du perimetre. 

8.2.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. Elle est decrite a la section 9.2.2.5. Cette technique permet d’evaluer les options 
identifies afin de selectionner les differentes options ou approches de qualite les mieux adaptees. 

♦ Analyse des documents. Elle est decrite a la section 5.2.2.3. L'analyse des differents documents issus des 
processus de maTtrise du projet, comme les rapports de qualite, de test, ou de performance et l'analyse des 
ecarts, peut indiquer et mettre en lumiere des processus susceptibles d’etre hors de controle et de compromettre 
la satisfaction des exigences specifies ou des attentes des parties prenantes. 

♦ Analyse des processus. L'analyse des processus identifie is opportunity d’amelioration des processus. Cette 
analyse examine egalement les probimes, les contraintes et les activites sans valeur ajoutee identifies pendant 
I’execution d’un processus. 

♦ Analyse des causes originelles. L’analyse des causes originelles est une technique analytique utilisee pour 
determiner la raison sous-jacente fondamentale qui genere un ecart, un defaut ou un risque. Une meme cause 
originelle peut etre sous-jacente a plusieurs ecarts, defauts ou risques. Eli peut egalement etre utilisee comme 
technique pour identifier is causes originelles d’un probime et is resoudre. Pour qu’un probime ne se 
represente plus, toutes ses causes originelles doivent etre eliminees. 
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8.2.2.3 PRISE DE DECISION 


Parmi les techniques de prise de decision pouvant etre utilisees dans le cadre de ce processus figure notamment 
I'analyse decisionnelle multicritere. Elle est decrite a la section 8.1.2.4. L’analyse decisionnelle multicritere permet 
d’evaluer plusieurs criteres lors de la discussion des alternatives ayant une influence sur la qualite du projet ou du 
produit. Les decisions du pro/'ef peuvent inclure la selection d’un scenario d’application ou d’un fournisseur. Les decisions 
du produit peuvent inclure revaluation du cout du cycle de vie, de I’echeancier, de la satisfaction des parties prenantes 
et des risques associes a la correction des defauts du produit. 

8.2.2.4 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Diagrammes d’affinite. Ils sont decrits a la section 5.2.2.5. Les diagrammes d’affinite peuvent organiser en groupes 
les eventuelles causes des defauts mettant en evidence les domaines qui meritent une attention particuliere. 

♦ Diagrammes cause-effet. Les diagrammes cause-effet sont egalement appeles diagrammes en arete de 
poisson (fishbone), diagrammes des 5 M ou diagrammes d’lshikawa. Ce type de diagramme decompose les 
causes de I’enonce du probleme en les repartissant sur des branches distinctes afin d’en identifier la cause 
principale ou originelle. La figure 8-9 illustre un exemple de diagramme cause-effet. 

♦ Diagrammes de flux. Ils sont decrits a la section 8.1.2.5. Les diagrammes de flux presented une serie d’etapes 
qui conduisent a un defaut. 

♦ Histogrammes. Les histogrammes sont une representation graphique des donnees numeriques. Ils indiquent le 
nombre de defauts par livrable, le classement des causes des defauts, le nombre de fois que chaque processus 
est non conforme ou les autres representations des defauts du projet ou du produit. 

♦ Diagrammes matriciels. Ils sont decrits a la section 8.1.2.5. Le diagramme matriciel vise a montrer la force des 
relations entre les facteurs, causes et objectifs qui existent entre les lignes et les colonnes qui torment la matrice. 

♦ Diagrammes de correlation. Un diagramme de correlation est un graphique qui presente la relation entre deux 
variables. II demontre la relation entre un element d’un processus, d’un environnement ou d’une activite sur un 
axe, et un defaut de qualite sur I’autre axe. 
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Figure 8-9. Diagramme cause-effet 


8.2.2.5 AUDITS 

Un audit est un processus structure et independant permettant de determiner si les activites du projet sont conformes 
aux politiques, aux processus et aux procedures de I’organisation et du projet. En regie generate, un audit qualite est 
realise par une equipe externe au projet. Celle-ci peut etre un service en charge de I'audit interne de I'organisation, 
le bureau des projets (Project Management Office, PMO), ou un auditeur externe a I’organisation. Ces objectifs d'audit 
qualite sont notamment: 

♦ identifier toutes les bonnes pratiques appliquees ; 

♦ identifier toutes les non-conformites, les lacunes et les imperfections ; 

♦ partager les bonnes pratiques introduites ou appliquees dans des projets similaires de I’organisation et/ou 
de I’industrie; 

♦ offrir proactivement une assistance positive, pour ameliorer I’application des processus afin d’optimiser la 
productivity de I’equipe; 

♦ souligner les contributions de chaque audit dans I’archive des retours d’experiences de I’organisation. 
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L’effort consecutif de correction des carences devrait resulter en une reduction du cout de la qualite et en une 
acceptation accrue du produit du projet par le sponsor ou le client. Les audits qualite peuvent etre planifies ou aleatoires, 
et etre conduits par des auditeurs internes ou externes. 

Les audits qualite peuvent enteriner I’application des demandes de changement approuvees, y compris des mises 
a jour, des actions correctives, des corrections des defauts et des actions preventives. 

8.2.2.6 DESIGN FOR X 

Design for X, ou DfX, est un ensemble de directives techniques pouvant etre appliquees lors de la conception d’un produit 
afin d’optimiser un aspect particular de la conception. DfX permet de maTtriser voire d’ameliorer les caracteristiques 
finales du produit. Le X dans DfX peut representer differents aspects du developpement de produit, comme la fiabilite, le 
deployment, le montage, la fabrication, le cout, I’entretien, la facilite d’utilisation, la securite et la qualite. DfX permet de 
reduire les couts, d’ameliorer la qualite, d’obtenir de meilleures performances et de satisfaire le client. 

8.2.2.7 RESOLUTION DE PROBLEMES 

La resolution de problemes suppose de trouver des solutions a des points a traiter ou des difficultes. Elle peut 
notamment inclure la collecte d’informations supplementaires, I’analyse critique, ainsi que des approches, creatives, 
quantitatives et/ou logiques. La resolution efficace et systematique des problemes est essentielle a I'assurance qualite 
et a I’amelioration de la qualite. Les problemes peuvent survenir suite au processus MaTtriser la qualite ou a des audits 
qualite. Ms peuvent etre associes a un processus ou a un livrable. Une methode de resolution de problemes structure 
aidera a eliminer le probleme et a elaborer une solution durable. Les methodes de resolution de problemes se composent 
generalement des elements suivants: 

♦ definition du probleme; 

♦ identification de la cause originelle; 

♦ proposition de solutions possibles ; 

♦ selection de la meilleure solution ; 

♦ application de la solution ; 

♦ verification de I’efficacite de la solution. 
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8.2.2.8 METHODES D’AMELIORATION DE LA QUALITE 


Les ameliorations de la qualite peuvent etre apportees sur la base des resultats et des recommandations des 
processus de maTtrise de la qualite, des conclusions des audits qualite ou de la resolution de problemes du processus 
Gerer la qualite. Le cycle Planifier-Derouler-Controler-Agir (PDCA) et Six Sigma sont les deux outils d’amelioration de la 
qualite les plus utilises pour analyser et evaluer les opportunity d’amelioration. 


8.2.3 GERER LA QUALITE : DONNEES DE SORTIE 

8.2.3.1 RAPPORTS DE QUALITE 

Les rapports de qualite peuvent etre graphiques, numeriques ou qualitatifs. Les informations fournies peuvent etre 
utilisees par d’autres processus et services afin de prendre des actions correctives pour satisfaire aux attentes de 
qualite du projet. Les informations presentees dans les rapports de qualite peuvent inclure tous les problemes de gestion 
de la qualite remontes par Pequipe, les processus recommandes, les ameliorations de projets et de produits, les actions 
correctives recommandees (y compris la reprise, la correction d’un defaut/dysfonctionnements et I’inspection complete, 
entre autres) et le recapitulate des resultats du processus MaTtriser la qualite. 

8.2.3.2 DOCUMENTS D’EVALUATION ET DETEST 

Les documents devaluation et de test peuvent etre crees en fonction des besoins du secteur et des modeles de 
I'organisation. Ce sont des donnees d’entree au processus MaTtriser la qualite. Ms sont utilises pour evaluer la realisation 
des objectifs de qualite. Ces documents peuvent comprendre des checklists dediees et des matrices de tragabilite des 
exigences detaillees. 

8.2.3.3 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Si des changements apportes lors du processus Gerer la qualite ont une 
influence sur I’un des composants du plan de management de projet, des documents du projet, des processus de 
management de projet ou des processus de gestion du produit, le chef de projet doit envoyer une demande de 
changement et suivre le processus MaTtriser les changements, tel que defini dans la section 4.6. 
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8.2.3.4 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. L'approche convenue pour gerer la qualite devra 
etre modifiee, si besoin, en fonction des resultats reels. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre peut 
changer suite a des activites specifiques de gestion de la qualite. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. La reference de base de I’echeancier 
peut changer suite a des activites specifiques de gestion de la qualite. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts peut changer 
suite a des activites specifiques de gestion de la qualite. 

8.2.3.5 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les nouveaux points a traiter souleves suite a ce 
processus sont consignes dans le journal correspondant. 

♦ Registre des retours d’experiences. II est decrit a la section 4.4.3.1. Le registre des retours d’experiences est 
mis a jour a I'aide des informations sur les difficulty rencontrees et les moyens pour les eviter ainsi que sur les 
approches qui ont permis de gerer la qualite. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 
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8.3 MAITRISER LA QUALITE 

MaTtriser la qualite est le processus qui consiste a maTtriser et enregistrer les resultats des activites de gestion de 
la qualite pour evaluer la performance et s’assurer de I’exhaustivite des donnees de sortie du projet, de leur exactitude 
et de leur capacite a satisfaire aux attentes des clients. L’interet principal de ce processus est qu’il permet de verifier 
que les travaux et les livrables du projet repondent aux exigences specifies par les principals parties prenantes pour 
I’acceptation finale. Le processus MaTtriser la qualite determine si les resultats du projet remplissent leur mission. 
Ces resultats doivent respecter I’ensemble des standards, des exigences, des regimentations et des specifications 
applicables. Ce processus est execute tout au long du projet. 

Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 8-10. La figure 8-11 represente le diagramme de flux de donnees de ce processus. 


Maitriser la qualite 


Donnees d’entree 


.1 Plan de management du projet 

• Plan de gestion de la qualite 
.2 Documents du projet 

• Registre des retours 
d'experience 

• Metriques qualite 

• Documents devaluation et 
de test 

.3 Demandes de changement 
approuvees 
.4 Livrables 

.5 Donnees de performance 
d'execution 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 
V___/ 


Outils et techniques 


.1 Collecte des donnees 

• Checklists 

• Fiches de controle 

• Echantillonnage statistique 

• Questionnaires et enquetes 
.2 Analyse des donnees 

• Revues de performance 

• Analyse des causes 
fondamentales 

.3 Inspection 

.4 Tests/evaluations du produit 
.5 Representation des donnees 

• Diagrammes cause-effet 

• Diagrammes de controle 

• Histogramme. 

• Diagrammes de correlation 
.6 Reunions 

V_/ 


Donnees de sortie 


.1 Mesures de controle 
de la qualite 
.2 Livrables verifies 
.3 Information sur 

la performance d'execution 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 

• Plan de gestion de la qualite 
.6 Mises a jour des documents 

du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Registre des risques 

• Documents devaluation et 
de test 

v_y 


Figure 8-10. Maitriser la qualite: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 8-11. Diagramme de flux de donnees du processus Maitriser la qualite 


Le processus Maitriser la qualite permet de mesurer I’exhaustivite, la conformite et I’aptitude a I’usage d’un produit 
ou d’un service avant I’acceptation par les utilisateurs et leur livraison finale. Pour ce faire, il convient de mesurer 
I'ensemble des etapes, des attributs et des variables utilises pour verifier la conformite ou le respect des specifications 
decrites lors de I’etape de planification. 

Le processus Martriser la qualite doit etre execute tout au long du projet afin de demontrer officiellement, a I'aide de 
donnees fiables, que les criteres d’acceptation du sponsor et/ou du client ont ete remplis. 
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Le niveau d’effort pour maTtriser la qualite et le degre de mise en oeuvre peuvent varier selon I’industrie et les styles 
de management de projet. Dans les industries pharmaceutiques, de la sante, du transport et du nucleaire, par exemple, 
les procedures de maTtrise de la qualite peuvent etre plus strictes par rapport aux autres industries. En outre, elles 
peuvent necessiter des efforts considerables pour respecter les standards etablis. Dans le cas des projets agiles, par 
exemple, tous les membres de I'equipe peuvent realiser les activites de maTtrise de la qualite tout au long du cycle de vie 
du projet. Pour les projets fondes sur des modeles de type waterfall, les activites de maTtrise de la qualite sont executees 
a des moments precis, vers la fin du projet ou de la phase, par certains membres de I'equipe. 


8.3.1 MAITRISER LA QUALITE : DONNEES D’ENTREE 

8.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le plan 
de gestion de la qualite. Ce dernier, decrit a la section 8.1.3.1, definit la fagon dont la maTtrise de la qualite sera effectuee 
dans le cadre du projet. 

8.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experiences. II est decrit a la section 4.4.3.1. Les retours d’experiences du debut du 
projet peuvent etre appliques aux phases ulterieures afin d’ameliorer la maTtrise de la qualite. 

♦ Metriques qualite. Elles sont decrites a la section 8.1.3.2. Une metrique qualite decrit, en termes specifiques, 
un attribut du projet ou du produit, et la fagon dont le processus MaTtriser la qualite en verifiera la conformite. 

♦ Documents devaluation et de test. Ms sont decrits a la section 8.2.3.2. Les documents devaluation et de test 
sont utilises pour evaluer la realisation des objectifs de qualite. 
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8.3.1.3 DEMANDES DE CHANGEMENT APPROUVEES 

Elies sont decrites a la section 4.6.3.1. Une mise a jour du registre des changements, qui fait partie du processus 
MaTtriser les changements, indique les changements approuves et ceux qui ne le sont pas. Les demandes de changement 
approuvees peuvent inclure la correction des defauts, la mise a jour des methodes de travail et des echeanciers. 
Les changements partiels peuvent entramer des incoherences et des retards si les etapes ou les corrections sont 
incompletes. L’application des changements approuves doit etre verifiee, confirmee pour en assurer I’integrite, testee 
de nouveau et certifiee comme correcte. 

8.3.1.4 LIVRABLES 

Un livrable est un produit, un resultat ou une capacite a realiser un service, de caractere unique et verifiable, qui 
doit etre produit pour achever un processus, une phase ou un projet. Les livrables, c’est-a-dire les donnees de sortie 
du processus Diriger et gerer le travail du projet, sont inspectes puis compares aux criteres d’acceptation definis dans 
I’enonce du perimetre du projet. 

8.3.1.5 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution comportent des renseignements sur 
I’etat du produit, comme les observations, les metriques qualite et les mesures des performances techniques, ainsi que 
des informations sur les performances de I'echeancier et des couts concernant la qualite du projet. 

8.3.1.6 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus MaTtriser la 
qualite, on peut citer: 

♦ le systeme d’information de management du projet (PMIS), c’est-a-dire le logiciel de gestion de la qualite 
permettant de suivre les erreurs et les variances des processus ou des livrables ; 

♦ les regimentations d’agences gouvernementales; 

♦ les regies, les standards et les directives specifiques a un domaine d’application. 
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8.3.1.7 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser la qualite, on peut citer: 

♦ les standards et les politiques de qualite; 

♦ les modeles de qualite, par exemple, les fiches de controle et les checklists ; 

♦ les procedures d'etablissement de rapports sur les points a traiter et les defauts, ainsi que les politiques 
de communication. 

8.3.2 MAITRISER LA QUALITE : OUTILS ET TECHNIQUES 
8.3.2.1 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Checklists. Elies sont decrites a la section 11.2.2.2. Les checklists permettent de gerer les activites MaTtriser la 
qualite de maniere structure. 

♦ Fiches de controle. Les fiches de controle sont egalement appelees feuilles de decompte. Elies permettent 
d’organiser les faits de maniere a faciliter la collecte de donnees utiles sur un eventuel probleme de qualite. 
Ces fiches sont particulierement utiles pour recueillir des donnees sur les attributs lors des inspections visant 
a identifier les defauts. II peut notamment s’agir de donnees relatives a la frequence ou aux consequences des 
defauts. Voir la figure 8-12. 



Date 1 

Date 2 

Date 3 

Date 4 

-^ 

Total 

Petite rayure 

l 

2 

2 

2 

7 

Grande rayure 

0 

1 

0 

0 

1 

Courbe 

3 

3 

1 

2 

9 

Composant manquant 

5 

0 

2 

1 

8 

Mauvaise couleur 

2 

0 

1 

3 

6 

Erreur d’etiquetage 

1 

2 

1 

2 

6 


Figure 8-12. Fiches de controle 
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♦ Echantillonnage statistique. L'echantillonnage statistique consiste a selectionner une partie de la population 
etudiee pour I’analyser (par exemple, une selection aleatoire de 10 dessins industriels dans une liste en 
comportant 75). L'echantillon est preleve afin de mesurer les controles et de verifier la qualite. La frequence et la 
taille de l’echantillon doivent etre determinees lors du processus Planifier la gestion de la qualite. 

♦ Questionnaires et enquetes. Les enquetes peuvent etre utilisees pour recueillir des donnees sur la satisfaction 
du client apres le deployment du produit ou du service. Les couts relatifs aux defauts identifies dans les enquetes 
peuvent etre qualifies de couts des defauts externes dans le modele de cout de la qualite. Ils peuvent avoir des 
consequences financieres importantes pour I’organisation. 

8.3.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Revues de performance. Les revues de performance permettent de mesurer, de comparer et d’analyser les 
metriques qualite definies par le processus Planifier la gestion de la qualite par rapport aux resultats reels. 

♦ Analyse des causes originelles. Elle est decrite a la section 8.2.2.2. L'analyse des causes originelles permet 
d’identifier I’origine des defauts. 

8.3.2.3 INSPECTION 

Une inspection est un examen du produit d’un travail visant a determiner s’il est conforme aux standards documents. 
En regie generate, les resultats des inspections incluent des mesures, et les inspections peuvent etre effectuees 
a n’importe quel niveau. Les resultats d’une seule activite ou le produit final du projet peuvent etre inspectes. Les 
inspections sont aussi appelees revues, evaluations par les pairs, audits ou revues structures. Dans certains domaines 
d'application, ces termes ont des sens particuliers et plus restreints. Les inspections permettent egalement de verifier 
les corrections des defauts. 

8.3.2.4 TESTS/EVALUATIONS DU PRODUIT 

L’activite test, comparable a une enquete organisee et structure, permet de fournir des informations objectives sur 
la qualite du produit ou du service teste, conformement aux exigences du projet. Le but est de detecter les erreurs, les 
defauts, les dysfonctionnements ou les autres non-conformites du produit ou du service. Le type, le nombre et I'ampleur 
des tests necessaires pour evaluer chaque exigence font partie du plan de la qualite du projet. Ils dependent de la nature, 
du delai, du budget et des autres contraintes du projet. Les tests peuvent etre realises tout au long du projet, au fur et a 
mesure de la disponibilite de ses differents composants, ainsi qu’a la fin du projet pour les livrables finaux. Les premiers 
tests aident a identifier les non-conformites et a reduire le cout des corrections des composants non conformes. 
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Chaque domaine d’application correspond a des tests differents. Par exemple, les tests logiciels peuvent inclure le test 
unitaire, le test d'integration, le test de la boTte noire et de la boTte blanche, le test des interfaces, le test de regression 
et le test alpha. Dans le cas des projets de construction, les tests peuvent inclure le test de resistance du ciment, le test 
d’ouvrabilite du beton, les essais non destructifs sur les sites de construction pour tester la qualite des structures en 
beton durci et les analyses du sol. Dans le cas du developpement du materiel, les tests peuvent notamment inclure le 
deverminage, les tests de rodage et les tests du systeme. 

8.3.2.5 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Diagrammes cause-effet. Ms sont decrits a la section 8.2.2.4. Les diagrammes cause-effet permettent 
d’identifier les effets possibles des defauts et des erreurs de qualite. 

♦ Diagrammes de controle. Les diagrammes de controle permettent de determiner si un processus est stable 
ou non, ou encore si sa performance est previsible ou non. Les limites de specifications superieure et inferieure 
se fondent sur les exigences. Elies refletent les valeurs minimum et maximum tolerees. Les limites de maTtrise 
superieure et inferieure se distinguent des limites de specifications. En effet, les limites de controle sont 
determinees selon des calculs et principes statistiques standardises afin d’etablir la capacite naturelle d’un 
processus stable. Le chef de projet et les parties prenantes appropriees peuvent utiliser les limites de controle, 
calculees sur des bases statistiques, pour identifier les points exigeant une action corrective visant a prevenir 
une performance qui reste hors des limites de controle. Les diagrammes de controle peuvent etre utilises pour 
maTtriser divers types de variables de donnees de sortie. Bien qu’ils soient utilises le plus souvent pour effectuer 
le suivi d’activites repetitives, telles que celles exigees pour produire des lots de fabrication, les diagrammes de 
controle peuvent egalement etre utilises pour maTtriser les ecarts de cout et de delais, le nombre et la frequence 
des changements du perimetre ou d'autres resultats de gestion, afin d'aider a determiner si les processus de 
management de projet sont sous controle. 

♦ Histogrammes. Ils sont decrits a la section 8.2.2.4. Les histogrammes peuvent demontrer le nombre de defauts 
par origine ou par composant. 

♦ Diagrammes de correlation. Ils sont decrits a la section 8.2.2.4. Les diagrammes de correlation montrent les 
performances planifiees sur un axe et les performances reelles sur I’autre axe. 
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8.3.2.6 REUNIONS 

Les reunions suivantes peuvent etre utilisees dans le cadre du processus MaTtriser la qualite. 

♦ Revue des demandes de changement approuvees. Chaque demande de changement approuvee doit etre 
passee en revue de fagon a verifier qu’elle a ete appliquee, conformement a I'approbation donnee. Cette revue 
doit egalement verifier que les changements partiels sont apportes et que toutes les parties ont ete correctement 
appliquees, testees, completes et certifies. 

♦ Retrospectives/retours d’experiences. L’equipe projet organise une reunion afin de discuter: 

■ des elements de reussite du projet/de la phase; 

■ des points a ameliorer; 

■ des elements a integrer au projet en cours et aux projets a venir; 

■ des ajouts a apporter aux actifs organisationnels. 

8.3.3 MAITRISER LA QUALITE : DONNEES DE SORTIE 

8.3.3.1 MESURES DE CONTROLE DE LA QUALITE 

Les mesures de controle de la qualite sont les resultats documents des activites de maitrise de la qualite. Ces 
mesures doivent etre prises selon le format specifie dans le plan de gestion de la qualite. 

8.3.3.2 LIVRABLES VERIFIES 

Un des buts du processus MaTtriser la qualite est de determiner la conformite des livrables. Les resultats de I'execution 
du processus MaTtriser la qualite sont des livrables verifies qui deviennent les donnees d’entree du processus Valider le 
perimetre (voir la section 5.5) en vue d’une acceptation formelle. En cas de demandes de changement ou d’ameliorations 
liees aux livrables, ils peuvent etre modifies, inspectes et verifies a nouveau. 

8.3.3.3 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d’execution inclut les informations sur le respect 
des exigences du projet, les causes de rejet, les reprises requises, les actions correctives recommandees, les listes de 
livrables verifies, I’etat des metriques qualite et les ajustements necessaires des processus. 
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8.3.3.4 DEMANDES DE CHANGEMENT 


Elies sont decrites a la section 4.3.3.4. Le chef de projet doit deposer une demande pour tout changement apporte 
durant le processus MaTtriser la qualite ayant une incidence sur I'un des composants du plan de management du projet 
ou les documents du projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser 
les changements (voir la section 4.6). 

8.3.3.5 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une demande 
de changement pour le plan de management du projet, figure le plan de gestion de la qualite decrit a la section 8.1.3.1. 

8.3.3. 6 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Un livrable qui ne satisfait pas aux exigences de 
qualite est souvent considere comme un point a traiter. 

♦ Registre des retours d’experiences. II est decrit a la section 4.4.3.1. Le registre des retours d’experiences est 
mis a jour a I'aide des informations sur I’origine des defauts de qualite, sur les moyens pour les eviter et sur les 
approches efficaces. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 

♦ Documents devaluation et de test. Ms sont decrits a la section 8.2.3.2. Les documents devaluation et de test 
peuvent etre modifies au terme de ce processus afin d’effectuer d’autres tests plus efficaces. 
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GESTION DES RESSOURCES DU PROJET 

La gestion des ressources du projet inclut les processus qui consistent a identifier, a obtenir et a gerer les ressources 
requises pour garantir I’achevement du projet. Ces processus veillent a ce que les bonnes ressources soient mises a 
disposition du chef de projet et de I’equipe projet au bon moment et au bon endroit. 

Les processus de gestion des ressources du projet sont les suivants : 

9.1 Planifier la gestion des ressources —Ce processus consiste a definir la methode d’estimation, d’obtention, 
de gestion et d’utilisation des ressources humaines et materielles du projet. 

9.2 Estimer les ressources necessaires aux activites —Ce processus consiste a evaluer les besoins en 
ressources d’une equipe mais aussi le type et les quantites du materiel, des equipements et des fournitures 
necessaires a la realisation des travaux du projet. 

9.3 Obtenir les ressources —Ce processus consiste a recruter les membres d’une equipe ainsi qu'a obtenir 
les infrastructures, les equipements, le materiel, les fournitures et toutes les autres ressources necessaires a la 
realisation des travaux du projet. 

9.4 Developper I’equipe —Ce processus consiste a ameliorer les competences des membres de I'equipe, leurs 
interactions et I’environnement global de I’equipe, afin d’ameliorer la performance du projet. 

9.5 Gerer I’equipe —Ce processus consiste a suivre la performance des membres de I’equipe, a fournir des 
retours d'information, a resoudre les points a traiter et a gerer les changements dans I'equipe pour optimiser la 
performance du projet. 

9.6 Maitriser les ressources —Ce processus consiste a s'assurer de la disponibilite des ressources allouees 
au projet, conformement aux previsions, a en suivre I’utilisation reelle par rapport aux previsions et a effectuer des 
actions correctives, le cas echeant. 

La figure 9-1 donne une vue d’ensemble des processus de gestion des ressources du projet. Les processus de 
gestion des ressources du projet sont presentes comme des processus distincts aux interfaces clairement definies 
tandis que, dans la pratique, leurs chevauchements et interactions ne peuvent etre completement detailles dans le 
Guide PMBOK®. 
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Vue d’ensemble de la gestion 
des ressources du projet 


9.1 Planifier la gestion 
des ressources 


.1 Donnees d'entree 
.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Representation des donnees 
.3 Systemes de I'organisation 
.4 Reunions 

.3 Donnees de sortie 
.1 Plan de gestion 
des ressources 
.2 Charte d'equipe 
.3 Mises a jour des documents 
du projet 

V___/ 


9.4 Developper l’equipe 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 
.1 Colocalisation 
.2 Equipes virtuelles 
.3 Technologie 
de communication 
.4 Competences 

interpersonnelles et d'equipe 
.5 Reconnaissance et 
recompenses 
.6 Formation 

.7 Evaluations des personnes 
et de I'equipe 
.8 Reunions 

.3 Donnees de sortie 

.1 Evaluations des performances 
de I'equipe 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

.5 Mises a jour des facteurs 
environnementaux 
de I'organisation 
.6 Mises a jour des actifs 
organisationnels 

V _/ 


9.2 Estimer les ressources 
necessaires aux activities 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Estimation ascendante 
.3 Estimation paranalogie 
.4 Estimation parametrique 
.5 Analyse des donnees 
.6 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.7 Reunions 

.3 Donnees de sortie 

.1 Besoins en ressources 
.2 Base des estimations 
.3 Organigramme des ressources 
.4 Mises a jour des documents 
du projet 

v ___y 


9.S Gerer l’equipe 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Rapports sur la performance 
d'execution 

.4 Evaluations des performances 
de I'equipe 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 

.2 Outils ettechniques 
.1 Competences 

interpersonnelles et d'equipe 
.2 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.3 Donnees de sortie 

.1 Demandes de changement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

.4 Mises a jour des facteurs 
environnementaux 
de I'organisation 

v___y 


9.3 Obtenir les ressources 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 
.1 Prise de decision 
.2 Competences 

interpersonnelles et d'equipe 
.3 Affectation prealable 
.4 Equipes virtuelles 

.3 Donnees de sortie 

.1 Affectations des ressources 
materielles 

.2 Affectations des membres 
de I'equipe projet 
.3 Calendriers des ressources 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour des documents 
du projet 

.7 Mises a jour des facteurs 
environnementaux 
de I’organisation 
.8 Mises a jour des actifs 
organisationnels 

v _y 


9.6 Maitriser 
les ressources 


.1 Donnees d'entree 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 
.4 Accords 

.5 Actifs organisationnels 

.2 Outils ettechniques 
.1 Analyse des donnees 
.2 Resolution de problemes 
.3 Competences 

interpersonnelles et d'equipe 
.4 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.3 Donnees de sortie 
.1 Information sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

v___y 


Figure 9-1. Vue d’ensemble de la gestion des ressources du projet 
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Le chef de projet a besoin de competences differentes pour gerer les ressources de I’equipe et les ressources 
materielles. Les ressources materielles incluent les equipements, le materiel, les installations et les infrastructures. Les 
ressources de I’equipe ou le personnel designent les ressources humaines. Le personnel possede des competences 
variees, travaille a temps plein ou a temps partiel, et peut venir en renfort ou quitter I’equipe au fur et a mesure que le 
projet avance. La gestion des ressources du projet et la gestion des parties prenantes du projet se recoupent legerement 
(voir la section 13). La section 9 est axee sur le sous-ensemble de parties prenantes qui constitue I’equipe projet. 

PRINCIPAUX CONCEPTS DE LA GESTION DES RESSOURCES DU PROJET 

L’equipe projet se compose de personnes investies de roles et de responsabilites qui travaillent ensemble en vue 
d’atteindre un objectif commun du projet. Le chef de projet doit deployer des efforts adequats afin d’obtenir, de gerer, 
de motiver et de responsabiliser I'equipe projet. Bien que chaque membre ait un role et des responsabilites specifiques, 
la participation de tous les membres de I'equipe a la planification du projet et a la prise de decisions est souhaitable. 
La participation des membres de I’equipe accroTt leur expertise au cours du processus de planification et renforce leur 
engagement dans le projet. 

Le chef de projet doit etre a lafois un guide et un responsable pour I’equipe projet. Outre les activites du management 
de projet, comme I’initialisation, la planification, I’execution, la maitrise et la cloture des differentes phases du projet, le 
chef de projet est responsable de la formation de I'equipe afin de constituer un groupe efficace. Le chef de projet doit 
etre conscient des differents aspects ayant une influence sur I’equipe, comme : 

♦ I’environnementde I’equipe; 

♦ la repartition geographique des membres de I’equipe; 

♦ la communication entre les parties prenantes; 

♦ la gestion des changements au sein de I'organisation ; 

♦ les politiques internes et externes ; 

♦ les problemes de nature culturelle et le caractere unique de I'organisation ; 

♦ les autres facteurs susceptibles d’alterer la performance du projet. 

Le chef de projet est egalement tenu de developper les competences de I'equipe de maniere proactive tout en 
maintenant et en ameliorant la satisfaction et la motivation de I’equipe. II doit non seulement etre sensibilise et adherer 
au comportement professionnel et ethique mais aussi s'assurer que tous les membres de I'equipe font de meme. 
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La gestion des ressources materielles vise a allouer et a utiliser les ressources materielles (materiel, equipements 
et fournitures, par exemple) necessaires a I'achevement efficace du projet. Pour cela, I'organisation doit disposer 
de donnees sur les demandes en ressources (immediatement et dans un avenir raisonnable), les configurations des 
ressources necessaires pour repondre a ces demandes et I’approvisionnement en ressources. L’echec de la gestion et 
maTtrise des ressources constituent une source de risque au bon achievement du projet. Par exemple : 

♦ I’incapacite a garantir la mise a disposition dans les temps des equipements ou de I’infrastructure necessaires 
peut entramer des retards de fabrication du produit fini; 

♦ la commande de materiaux de mauvaise qualite risque d’alterer la qualite du produit, augmentant ainsi le nombre 
de rappels ou de reprises; 

♦ un surplus de stock peut engendrer une hausse des couts d’exploitation et une diminution du profit de 
I’organisation ; un niveau de stock trap bas ne permet a I’inverse pas de satisfaire a la demande du client et, la 
encore, peut engendrer une diminution du profit de I’organisation. 

TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES RESSOURCES DU PROJET 

Les styles de management de projet sont en train de passer d’une structure de commandement et de controle de la 
gestion des projets a une approche de gestion plutot axee sur la collaboration et I'accompagnement qui responsabilise 
I’equipe en lui delegant la prise de decision. En outre, les approches de la gestion des ressources du projet visent a 
optimiser I’utilisation des ressources. Les tendances et pratiques emergentes en gestion des ressources du projet 
comprennent notamment les elements suivants : 

♦ Methodes de gestion des ressources. Au cours des dernieres annees, plusieurs tendances ont emerge dans 
certains secteurs en raison de la rarete des ressources critiques. II existe de nombreuses publications sur le 
lean management, la fabrication a flux tendu (just-in-time, JIT), le Kaizen, la maintenance productive totale (total 
productive method, TPM), la theorie des contraintes (theory of constraints, TOC) et d’autres methodes. Un chef 
de projet doit determiner si I'organisation realisatrice a adopte au moins un outil de gestion des ressources et 
I’a adapte au projet. 

♦ Intelligence emotionnelle. Le chef de projet doit investir dans I’intelligence emotionnelle en ameliorant les 
competences internes (par exemple, I'autogestion et la conscience de soi) et externes (par exemple, la gestion 
des relations). Selon les recherches, les equipes projet qui parviennent a developper leur intelligence emotionnelle 
ou qui deviennent des groupes competents sur le plan affectif sont plus efficaces. De plus, le taux de rotation du 
personnel est inferieur. 

♦ Equipes auto-organisees. La generalisation des approches agiles, principalement pour I’execution de projets 
informatiques, s'est traduite par I'emergence de I’equipe auto-organisee qui ne necessite aucun controle 
centralise. Dans le cas des projets confies a des equipes auto-organisees, le role du chef de projet (qui peut avoir 
un autre titre) consiste a offrir a I’equipe I'environnement et I'accompagnement necessaires mais aussi a lui faire 
confiance pour mener le projet a bien. En regie generate, les equipes auto-organisees efficaces se composent 
de specialistes generaux et non pas d’experts dans un domaine, qui s'adaptent constamment a revolution de 
I'environnement et acceptent les remarques constructives. 
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♦ Equipes virtuelles/distribuees. La globalisation des projets a encourage le besoin de constituer des equipes 
virtuelles dediees a un meme projet mais dispersees au niveau geographique. La constitution de ces equipes 
est rendue possible par I’emergence de technologies de communication telles que le courrier electronique, 
les conferences audio, les medias sociaux, les reunions en ligne sur Internet et la videoconference. La gestion 
des equipes virtuelles offre des avantages uniques, comme la capacity a utiliser une expertise specialist 
pour I’equipe projet lorsque I’expert n'est pas sur place, (’integration d’employes qui travaillent a domicile et 
I’incorporation de personnes en situation de handicap ou a mobility reduite. Les difficultes liees a la gestion des 
equipes virtuelles resident principalement dans le domaine de la communication. II s’agit notamment d’eventuels 
sentiments d’isolement, de lacunes au niveau du partage des connaissances et des experiences parmi les 
membres de I'equipe, de difficultes a suivre I'avancement et la productivity, des eventuels decalages horaires et 
des differences culturelles. 

CONSIDERATIONS RELATIVES A L’ADAPTATION 

Chaque projet etant unique, le chef de projet devra adapter I’application de chacun des processus de gestion des 
ressources du projet. Parmi les considerations relatives a I’adaptation, on peut citer les elements suivants : 

♦ Diversity. Quelle experience I’equipe a-t-elle de la diversity ? 

♦ Emplacement physique. Ou se trouvent les membres de I’equipe et les ressources materielles ? 

♦ Ressources propres au secteur. Quelles sont les ressources speciales necessaires au secteur ? 

♦ Recrutement des membres de i’equipe. Comment seront recrutes les membres de I’equipe pour le projet ? Les 
membres de I'equipe travailleront-ils a temps plein ou a temps partiel sur le projet ? 

♦ Gestion de I’equipe. Comment le developpement de I’equipe est-il gere dans le cadre du projet ? Existe-t-il 
des outils organisationnels pour gerer le developpement de I’equipe ? Faut-il en etablir de nouveaux ? Certains 
membres de I’equipe ont-ils des besoins speciaux ? L’equipe devra-t-elle etre formee a la gestion de la diversity ? 

♦ Approches du cycle de vie. Quelle approche du cycle de vie sera utilisee pour le projet ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les projets a forte variability sont confies a des structures d’equipe ciblees et collaboratives, comme les equipes 
auto-organisees composees de specialistes. 

La collaboration vise a accroTtre la productivity et a promouvoir une resolution des problemes de fagon innovante. 
Les equipes collaboratives peuvent faciliter I’integration acceleree de certaines activites, ameliorer la communication, 
favoriser le partage des connaissances et garantir des affectations flexibles des taches en plus d’autres benefices. 
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Si les avantages de la collaboration s'appliquent egalement aux autres environnements de projet, les equipes 
collaborates sont souvent determinates pour la reussite des projets presentant une forte variabilite et des changements 
rapides, car il y a moins de temps pour la centralisation des taches et la prise de decision. 

La planification des ressources humaines et materielles est beaucoup moins previsible pour les projets a forte 
variabilite. Dans ces environnements, les accords d’approvisionnement rapide et les methodes lean sont essentiels 
pour pouvoir martriser les couts et respecter I’echeancier. 


9.1 PLANIFIER LA GESTION DES RESSOURCES 

Planifier la gestion des ressources est le processus qui consiste a definir la methode d’estimation, d’obtention, de 
gestion et d’utilisation des ressources materielles et d’une equipe projet. L’interet principal de ce processus reside dans 
le fait qu’il etablit I'approche et le niveau d’effort necessaires a la gestion des ressources du projet en fonction du type 
et de la complexite de ce dernier. Ce processus est execute au moins une fois ou a plusieurs moments predefinis durant 
le projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 9-2. La figure 9-3 presente le diagramme de flux de donnees du processus. 


Planifier la gestion des ressources 


Donnees d’entree V Outils et techniques W Donnees de sortie 


.1 Charte du projet 

.2 Plan de management du projet 

• Plan de gestion de la qualite 

• Reference de base 
du perimetre 

.3 Documents du projet 

• Echeancier du projet 

• Documentation 
des exigences 

• Registre des risques 

• Registre des parties 
prenantes 

.4 Facteurs environnementaux 
de I’orga nisation 
.5 Actifs organisationnels 

V_I_y 


.1 Jugement a dire d'expert 
.2 Representation des donnees 

• Diagrammes hierarchiques 

• Matrice des responsabilites 

• Formats de type texte 

.3 Systemes de I'organisation 
.4 Reunions 

V_ J 


.1 Plan de gestion 
des ressources 
.2 Charte d'equipe 
.3 Mises a jour des documents 
du projet 

• Journaldes hypotheses 

• Registre des risques 

V ___/ 


Figure 9-2. Planifier la gestion des ressources: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 9-3. Planifier la gestion des ressources: diagramme de flux de donnees 


La planification des ressources permet d’identifier une approche visant a garantir la mise a disposition de ressources 
suffisantes pour I’achevement du projet. Les ressources du projet sont constitutes des membres de I’equipe, des 
fournitures, du materiel, des equipements et des installations. Une planification des ressources efficace doit s’interesser 
a la disponibilite de ressources humaines rares ou limitees, ou a leur concurrence. 

Ces ressources peuvent provenir des actifs internes ou de I’exterieur de I'organisation par le biais du processus 
approvisionnement. II est possible que d’autres projets necessitent les memes ressources au meme moment et au 
meme endroit. Cela peut impacter les couts, les echeanciers, les risques, la qualite et les autres domaines du projet. 
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9.1.1 PLANIFIER LA GESTION DES RESSOURCES : DONNEES D’ENTREE 


9.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet donne une description generate du projet et de ses exigences. 
Elle contient egalement la liste des parties prenantes, un recapitulate des jalons et les ressources financiers 
preapprouvees susceptibles d’influencer la gestion des ressources du projet. 

9.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. Le plan de gestion de la qualite aide a definir le 
niveau des ressources necessaires pour atteindre et maintenir le niveau de qualite et les mesures definis pour 
le projet. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre 
identifie les livrables qui motivent les types et les quantites de ressources a gerer. 

9.1.1.3 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet presente les delais pour les 
ressources necessaires. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. Ce sont les exigences qui dictent le type et 
la quantite des ressources necessaires au projet. Elies peuvent egalement avoir une influence sur leur gestion. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques comporte des informations 
relatives aux menaces et aux opportunity susceptibles d’avoir un impact sur la planification des ressources. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes aide a 
identifier les parties prenantes particulierement interessees par les ressources necessaires au projet, ou ayant 
un impact sur celles-ci. II permet egalement d’identifier les parties prenantes pouvant avoir une influence sur 
I’utilisation d’une ressource specifique. 
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9.1.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion des ressources, on peut citer: 

♦ la culture et la structure organisationnelles ; 

♦ la repartition geographique des installations et des ressources ; 

♦ les competences et la disponibilite des ressources existantes ; 

♦ les conditions du marche. 

9.1.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion des ressources, 
on peut citer: 

♦ les politiques et les procedures en matiere de ressources humaines ; 

♦ les politiques et les procedures en matiere de gestion des ressources materielles; 

♦ les politiques en matiere de surete ; 

♦ les politiques en matiere de securite ; 

♦ les modeles du plan de gestion des ressources ; 

♦ les donnees historiques de projets similaires. 

9.1.2 PLANIFIER LA GESTION DES RESSOURCES : OUTILS ET TECHNIQUES 
9.1.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ negotiation des meilleures ressources au sein de I’organisation ; 

♦ gestion des talents et developpement du personnel; 

♦ determination du niveau d’effort initial necessaire pour atteindre les objectifs du projet; 

♦ determination des exigences de compte-rendu en fonction de la culture organisationnelle ; 

♦ estimation des delais necessaires au recrutement, en se basant sur le retour d’experience et les conditions 
du marche; 

♦ identification des risques associes aux plans d’obtention, de maintien et de disengagement des ressources ; 

♦ respect des regimentations applicables des syndicats et du gouvernement; 

♦ gestion des fournisseurs et de I'aspect logistique afin de garantir la disponibilite dans le temps des materiaux 
et des fournitures. 
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9.1.2.2 REPRESENTATION DES DONNEES 


Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment les 
diagrammes. II existe differents formats pour documenter et communiquer les roles et les responsabilites des membres 
de I’equipe. La plupartsont classes a I'aide des formats hierarchiques, matriciels ou de type texte. Certaines affectations 
au projet sont repertories dans des plans subsidiaires, comme les plans de gestion des risques, de la qualite ou de la 
communication. Independamment de la methode utilisee pour documenter les roles des membres de I’equipe, I’objectif 
est de s'assurer que chaque lot de travaux a un responsable formellement identifier et que tous les membres de I’equipe 
comprennent clairement leurs roles et leurs responsabilites. Un format hierarchique permet de representer les roles 
generaux, tandis que le format de type texte est mieux adapte pour documenter les responsabilites detaillees. 

♦ Diagrammes hierarchiques. La structure d’organigramme traditionnelle peut etre utilisee pour mettre en 

evidence les postes et les relations dans un graphique en format descendant. 

■ Organigramme des travaux du projet (work breakdown structure, WBS). Le WBS, qui presente la fagon dont 
les livrables du projet sont decomposes en lots de travaux, offre un moyen de mettre en evidence les grands 
domaines de responsabilite. 

■ Organigramme fonctionnel. Alors que le WBS montre un decoupage des livrables du projet, I’organigramme 
fonctionnel est structure en fonction des unites, des equipes ou des services existants de I’organisation, 
avec les activites du projet ou les lots de travaux repertories en relation avec chacun des services. Ainsi, 
un service operationnel, tel que le service informatique ou celui des achats, pourra voir I’ensemble de ses 
responsabilites pour un projet en consultant la partie de I'organigramme fonctionnel le concernant. 

■ Organigramme des ressources. L'organigramme des ressources est une liste hierarchique des ressources 
materielles et humaines, identifies et classees par categorie et par type, qui permet de planifier, gerer 
et controler les travaux du projet. Chaque niveau decroissant (inferieur) correspond a une description plus 
detaillee de la ressource, jusqu'a ce que I’information soit suffisamment precise pour etre utilisee avec 
I’organigramme des travaux du projet et permettre la planification et la maitrise des travaux. 
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♦ Matrice des responsabilites. Une matrice des ressources du projet affectees a chaque lot de travail. La matrice 
des responsabilites (RAM), un exemple de diagramme matriciel, presente les ressources du projet affectees a 
chacun des lots de travaux. Cette matrice est utilisee pour illustrer les relations entre les lots de travaux, ou les 
activites, et les membres de I’equipe projet. Dans le cas de projets de plus grande envergure, les matrices des 
responsabilites peuvent etre elaborees sur plusieurs niveaux. Par exemple, une matrice des responsabilites de 
niveau general definit les responsabilites d’une equipe projet, d’un groupe ou d’une unite au sein de chaque 
composant du WBS. Les matrices des responsabilites de niveau plus precis sont utilisees au sein du groupe 
pour designer les roles, les responsabilites et les niveaux d’autorite d’activites specifiques. Le format matriciel 
montre I’ensemble des activites associees a une personne et I'ensemble des personnes associees a une activite. 
Cela permet egalement de s’assurer qu’une seule personne est responsable de chaque tache afin d’eviter toute 
confusion quant a qui dirige en dernier lieu la tache ou qui en a I’autorite. Un exemple d’une matrice des 
responsabilites est une matrice RACI qui signifie en anglais « Responsible (R), Accountable (A), Consulted (C), 
Informed (I)»et que I'on peuttraduire en frangais par Realisateur (R), Approbateur (A), Consulte (C), Informe (I). Elle 
est representee a la figure 9-4. La matrice fournie en exemple montre le travail a effectuer sous forme d’activites 
dans la colonne de gauche. Les ressources affectees peuvent etre representees sous forme de personnes ou de 
groupes. Le chef de projet peut choisir d’autres options, telles que les designations «leader»et« participant», 
selon qu’elles se pretent au projet. Une matrice RACI est un outil utile qui permet d’affecter des roles et des 
responsabilites de maniere claire lorsque I’equipe est constitute de ressources internes et externes. 

♦ Formats de type texte. Les responsabilites des membres de I’equipe qui necessitent des descriptions detaillees 
peuvent etre specifies a I’aide de formats de type texte. Generalement synthetiques, ces documents fournissent 
des informations telles que les responsabilites, I'autorite, les competences et les qualifications. Ces documents 
sont connus sous differentes appellations, notamment«description de poste»et«formulaire role-responsabilite- 
autorite». Ces documents peuvent etre utilises comme modeles pour des projets futurs, notamment lorsque les 
informations sont mises a jour tout au long du projet en cours par la prise en compte des retours d’experience. 


Matrice RACI 

Personne 

Activite 

Ann 

Ben 

Carlos 

Dina 

Ed 

Creer la matrice 

A 

R 

1 

1 

1 

Recueillir 
les exigences 

1 

A 

R 

C 

C 

Soumettre la demande 
de changement 

1 

A 

R 

R 

C 

Elaborer le plan 
d’essai 

A 

C 

1 

1 

R 


R = Responsible [Realise] A = Accountable [Rend des comptes] 

C = Consult [Consulte] 1 = Inform [Informe] 


Figure 9-4. Exemple de matrice RACI 
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9.1.2.3 THEORIE DES ORGANISATIONS 


La theorie des organisations fournit des informations sur le comportement des personnes, des equipes et des unites 
organisationnelles. Une utilisation efficace des techniques usuelles identifies dans la theorie des organisations permet 
de reduire le temps, le cout et les efforts necessaires a la creation des donnees de sortie du processus Planifier la 
gestion des ressources et d’ameliorer I’efficience de cette planification. Les theories des organisations applicables 
peuvent recommander I’exercice d’un style de leadership flexible qui s’adapte aux changements du degre de maturite 
de I'equipe au fil du cycle de vie du projet. II est important de reconnaTtre I’impact qu’ont la culture et la structure de 
I'organisation sur la structure organisationnelle du projet. 

9.1.2.4 REUNIONS 

L’equipe projet peut tenir des reunions afin de planifier la gestion des ressources du projet. 


9.1.3 PLANIFIER LA GESTION DES RESSOURCES : DONNEES DE SORTIE 

9.1.3.1 PLAN DE GESTION DES RESSOURCES 

Le plan de gestion des ressources, en tant que partie du plan de management du projet, fournit des indications sur la 
fagon dont les ressources du projet doivent etre classees, allouees, gerees et desengagees. II peut etre divise en plan de 
gestion de I'equipe et en plan de gestion des ressources materielles en fonction des caracteristiques du projet. Le plan 
de gestion des ressources inclut notamment les elements suivants : 

♦ Identification des ressources. Methodes d’identification et de quantification des ressources materielles et de 

I'equipe necessaires. 

♦ Obtention de ressources. Conseils sur la fagon d’obtenir les ressources materielles et de I'equipe pour le projet. 

♦ Roles et responsabilites. 

■ Role. Fonction assumee ou attribute a une personne dans le cadre du projet. Des exemples de roles de projet 
sont, entre autres, ingenieur en travaux publics, analyste d’affaires ou coordinateur de tests. 

■ Autorite. Droits d’affecter des ressources au projet, de prendre des decisions, de signer des accords, d'accepter 
des livrables et d’influencer les autres dans le but d’executer les travaux du projet. Parmi les exemples de 
decisions qui exigent une autorite clairement definie, on peut citer le choix de la methode d’execution d’une 
activite, les criteres d'acceptation de la qualite et la fagon de repondre aux ecarts du projet. Les membres de 
I’equipe sont plus performants lorsque leur niveau d’autorite correspond a leurs responsabilites individuelles. 
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■ Responsabilite. Fonctions et travail qui sont attendus de la part d’un membre de I’equipe projet dans le but de 
mener a terme les activites du projet. 

■ Competence. Aptitudes et capacite requises pour executer les activites assignees dans les limites des 
contraintes du projet. Si les membres de i’equipe projet ne possedent pas les competences requises, la 
performance risque d’etre compromise. Lorsque de telles inadequations sont identifiees, des reponses 
proactives, telles que la formation, I’embauche ou bien des changements de I’echeancier ou du perimetre, 
sont entreprises. 

♦ Organigrammes du projet. Representation graphique des membres de I’equipe projet et de leurs relations 
hierarchiques. Elle peut etre formelle ou informelle, tres detaillee ou peu detaillee, en fonction des besoins du 
projet. Par exemple, I’organigramme du projet pour une equipe d’intervention rassemblant 3 000 personnes en 
cas de catastrophe sera plus detaille qu’un organigramme pour un projet interne impliquant une vingtaine de 
personnes seulement. 

♦ Gestion des ressources du projet. Conseils sur la fagon de definir, de constituer, de gerer et, par la suite, de 
desengager les ressources de Pequipe projet. 

♦ Formation. Strategies de formation des membres de I’equipe. 

♦ Developpement de i’equipe. Methodes pour developper I’equipe projet. 

♦ Maitrise des ressources. Methodes pour garantir la disponibilite des ressources materielles adequates et 
optimiser I’obtention de ressources materielles en fonction des besoins du projet. Sont comprises les informations 
sur la gestion des stocks, des equipements et des fournitures tout au long du cycle de vie du projet. 

♦ Plan de reconnaissance. Reconnaissance, recompenses et date a laquelle elles seront decernees aux membres 
de I'equipe. 

9.1.3.2 CHARTE D’EQUIPE 

La charte d’equipe est un document qui definit les directives de fonctionnement, les accords et les valeurs de 
I’equipe. Elle contient notamment: 

♦ les valeurs de I’equipe; 

♦ les directives en matiere de communication ; 

♦ les criteres et le processus de prise de decision ; 

♦ le processus de resolution des conflits ; 

♦ les directives en matiere de reunion ; 

♦ les accords de I’equipe. 
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La charte d’equipe fixe clairement les attentes concernant le comportement souhaite de la part des membres de 
I’equipe projet. Une adhesion au plus tot a des directives claires permet de diminuer les malentendus et d’accroTtre la 
productivity. Les discussions autour de themes, tels que les codes de conduite, la communication, la prise de decision 
et les comportements lors des reunions, permettent de clarifier les valeurs des membres de I’equipe projet. La charte 
d’equipe a plus d’impact si elle est elaboree par I’equipe ou si cette derniere peut, au moins, y contribuer. Tous les 
membres de I'equipe projet doivent veiller au respect des roles indiques dans la charte d’equipe. Elle peut etre mise a 
jour periodiquement afin d’assurer une comprehension constante des regies de base de I'equipe mais aussi d’orienter 
et d’integrer les nouveaux membres de I’equipe. 

9.1.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le registre des hypotheses est mis a jour avec le 
changement d’hypotheses concernant la disponibilite, les exigences logistiques et I’emplacement des ressources 
materielles ainsi que les ensembles de competences et la disponibilite des ressources de I'equipe. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour avec les risques 
associes a la disponibilite des ressources materielles et humaines ou les autres risques connus lies aux ressources. 


9.2 ESTIMER LES RESSOURCES DES ACTIVITIES 

Estimer les ressources des activites est le processus qui consiste a evaluer les besoins en ressources d’une equipe 
mais aussi le type et les quantites de materiel, d’equipement et des fournitures necessaires a la realisation des travaux 
du projet. L’interet principal de ce processus reside dans le fait qu'il identifie le type, la quantity et les caracteristiques 
des ressources requises pour executer le projet. Ce processus est execute periodiquement pendant toute la duree du 
projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont representes a la 
figure 9-5. La figure 9-6 presente le diagramme de flux de donnees de ce processus. 
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Estimer les ressources necessaires aux activities 


Donnees d’entree H Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
des ressources 

• Reference de base 
du perimetre 

.2 Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Estimations de couts 

• Calendriers des ressources 

• Registre des risques 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

v___y 


.1 Jugement a dire d'expert 
.2 Estimation ascendante 
.3 Estimation par analogie 
.4 Estimation parametrique 
.5 Analyse des donnees 
• Analyse des alternatives 
.6 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.7 Reunions 

V_/ 


.1 Besoins en ressources 
.2 Base des estimations 
.3 Organigramme 
des ressources 

.4 Mises a jour des documents 
du projet 

• Attributs des activites 

• Journaldes hypotheses 

• Registre des retours 
d'experience 

v___y 


Figure 9-5. Estimer les ressources necessaires aux activites: donnees d’entree, outils, techniques et donnees de sortie 


Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion des ressources 

• Reference de base du perimetre 


Documents 
du projet 


Documents du projet 

• Attributs des activites 

• Liste d'activites 

• Journal des hypotheses 

• Estimations de couts 

• Calendriers des ressources 

• Registre des risques 


Entreprise/ 

Organisation 


9.2 

Estimer 
les ressources 
necessaires 
aux activites 


1 Besoins en ressources 
1 Base des estimations 
1 Organigramme 
des ressources 



Mises a jour des documents 
du projet 

• Attributs des activites 

• Journal des hypotheses 

• Registre des retours 
d'experience 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 9-6. Diagramme de flux de donnees du processus Estimer les ressources des activites 
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Le processus Estimer les ressources des activites est etroitement coordonne avec d’autres processus comme Estimer 
les couts. Par exemple: 

♦ L’equipe d’un projet de construction devra connaTtre les reglementations locales en matiere de construction. 
Une telle connaissance est souvent facilement disponible aupres des fournisseurs locaux. Si la main d’oeuvre 
interne manque d’experience dans des techniques de construction inhabituelles ou specialises, il est possible 
d’inclure le cout additionnel d’un consultant dans le budget comme moyen le plus efficace pour garantir cette 
connaissance des reglementations locales de construction. 

♦ L’equipe d’un projet de conception automobile devra connaitre les toutes dernieres techniques d’assemblage 
automatise. La connaissance requise peut etre obtenue soit en ayant recours aux services d’un consultant, soit 
en faisant participer un concepteur a un seminaire sur la robotique ou en incorporant dans I'equipe projet une 
personne issue de la production. 

9.2.1 ESTIMER LES RESSOURCES NECESSAIRES AUX ACTIVITES : DONNEES D’ENTREE 

9.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources definit 
I’approche qui permet d’identifier les ressources necessaires au projet. Par ailleurs, il definit et regroupe les 
methodes pour quantifier les ressources necessaires a chacune des activites. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre 
identifie le perimetre du projet et le contenu du produit necessaires pour atteindre les objectifs du projet. Le 
perimetre comprend les besoins en ressources materielles et de I'equipe. 

9.2.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Attributs des activites. Ms sont decrits a la section 6.2.3.2. Les attributs des activites fournissent la principale 
source de donnees utilisees lors de I’estimation des ressources materielles et de I’equipe necessaires a chacune 
des activites de la liste d’activites. Les attributs sont, par exemple, les besoins en ressources, les dates imposees, 
le lieu de I'activite, les hypotheses et les contraintes. 

♦ Liste d’activites. Elle est decrite a la section 6.2.3.1. La liste d’activites identifie les activites qui auront besoin 
de ressources. 
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♦ Registre des hypotheses. II est decrit a la section 4.1.3.2. Le registre des hypotheses peut contenir des 
informations sur les facteurs de productivite, la disponibilite, les estimations de couts et les approches de travail 
qui auront une influence sur la nature et le nombre de ressources materielles et de I’equipe. 

♦ Estimations de couts. Elies sont decrites a la section 7.2.3.1. Le cout des ressources peut avoir une influence 
sur leur choix en termes de quantite et de niveau de competence. 

♦ Calendriers des ressources. Le calendrier des ressources identifie les jours ouvres, les rotations d’equipe, les 
heures normales de travail, les fins de semaine et les jours feries de chaque ressource disponible. Les informations 
concernant les ressources, telles que les ressources de I’equipe, les equipements et le materiel, potentiellement 
disponibles pendant la conduite des activites prevues sont employees pour estimer I’utilisation des ressources. 
Les calendriers des ressources specified egalement quand et pour quelle duree les ressources materielles et de 
I’equipe identifies seront disponibles pendant le projet. Ces informations peuvent etre au niveau de I’activite ou 
du projet. Les attributs, tels que I’experience et/ou le niveau de competence des ressources sont pris en compte 
ainsi que les differents emplacements geographiques. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques decrit les risques individuels 
susceptibles d’avoir une influence sur le choix et la disponibilite des ressources. 

9.2.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Estimer les 
ressources des activites, on peut citer: 

♦ I’emplacement des ressources ; 

♦ la disponibilite des ressources ; 

♦ les competences des ressources de I'equipe; 

♦ la culture organisationnelle ; 

♦ les donnees d’estimation publiees; 

♦ les conditions du marche. 
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9.2.1.4 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Estimer les ressources des activites, 
on peut citer: 

♦ les politiques et les procedures concernant I'allocation des ressources humaines; 

♦ les politiques et les procedures concernant les fournitures et les equipements ; 

♦ les donnees historiques concernant les types de ressources utilisees pour un travail similaire au cours de 
projets anterieurs. 

9.2.2 ESTIMER LES RESSOURCES DES ACTIVITES : OUTILS ET TECHNIQUES 

9.2.2.1 JUGEMENTA DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation a la planification et a I’estimation des ressources materielles et d’equipe. 

9.2.2.2 ESTIMATION ASCENDANTE 

Elle est decrite a la section 6.4.2.5. Les ressources materielles et de I’equipe sont estimees au niveau de I’activite 
puis cumulees afin d’elaborer des estimations au niveau des lots de travaux, des centres de consolidation et des 
recapitulates de projet. 

9.2.2.3 ESTIMATION PAR ANALOGIE 

Elle est decrite a la section 6.4.2.2. L’estimation par analogie utilise les informations sur les ressources d’un projet 
anterieur similaire comme base pour estimer un futur projet. Cette methode d'estimation rapide peut etre utilisee 
lorsque le chef de projet ne peut identifier que certains niveaux superieurs du WBS. 

9.2.2.4 ESTIMATION PARAMETRIQUE 

Elle est decrite a la section 6.4.2.3. L’estimation parametrique utilise un algorithme ou une relation statistique entre 
les donnees historiques et les autres variables pour calculer les quantites de ressources necessaires a une activite, en 
fonction des donnees historiques et des parametres du projet. Par exemple, une activite qui necessite 4 000 heures 
de codage et 1 annee pour y parvenir aura besoin de deux personnes (chacune travaillant 2 000 heures par an). Cette 
technique permet d’obtenir des resultats d’un plus grand niveau d’exactitude, en relation avec la sophistication du 
modele et les donnees qu’il comporte. 
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9.2.2.5 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees utilisees pour ce processus figure notamment I'analyse des alternatives. 
Elle permet d’evaluer et de selectionner des options ou approches identifies d’execution et de realisation des travaux 
du projet. Bon nombre d’activites disposent de plusieurs options. On peut citer I’utilisation de differents niveaux de 
capacite ou de competences des ressources, des machines de taille ou de type divers, de differents outils (manuels ou 
automatiques) et des decisions de produire, louer ou acheter les ressources. L’analyse des alternatives aide a trouver la 
meilleure solution pour realiser les activites du projet tout en respectant les contraintes definies. 

9.2.2.6 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Le systeme d’information de management du projet peut inclure le logiciel de gestion 
des ressources qui permet de planifier, d’organiser et de gerer I’ensemble des ressources mais aussi d'etablir des 
estimations de ressources. Selon le niveau de sophistication du logiciel, il est possible de definir I’organigramme, la 
disponibilite et le cout des ressources, et les differents calendriers des ressources pour aider a optimiser I’utilisation de 
ces ressources. 

9.2.2.7 REUNIONS 

Le chef de projet peut tenir des reunions de planification avec des responsables fonctionnels pour estimer les 
ressources necessaires pour chaque activite, le niveau d’effort (level of effort, LoE), le niveau de competence des 
ressources de I'equipe et les quantites de materiel requises. Les participants a ces reunions peuvent comprendre le 
chef de projet, le sponsor du projet, des membres choisis de I’equipe projet, des parties prenantes et d'autres personnes 
selon les besoins. 


9.2.3 ESTIMER LES RESSOURCES DES ACTIVITES : DONNEES DE SORTIE 

9.2.3.1 BESOINS EN RESSOURCES 

Les besoins en ressources identifient le type et la quantite de ressources necessaires pour chaque lot de travaux ou 
activite dans un lot de travaux. Ms peuvent etre regroupes afin de determiner les ressources estimees pour les lots de 
travaux, les branches du WBS et le projet dans son integrality. Les niveaux de detail et de specificite des descriptions 
des besoins en ressources peuvent varier en fonction du domaine d’application. La documentation des besoins en 
ressources peut comprendre les hypotheses emises lors de la determination du type de ressources, de leur disponibilite 
et des quantites necessaires. 
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9.2.3.2 BASE DES ESTIMATIONS 


Elle est decrite a la section 6.4.3.2. Le volume et le type de details supplemental utilises dans I’estimation 
des ressources dependent du domaine d’application. Quel que soit le niveau de detail, la documentation fournie doit 
permettre une comprehension claire et exhaustive de la fagon dont I'estimation des ressources a ete obtenue. 

Les details a I’origine des estimations des ressources peuvent comprendre : 

♦ la methode utilisee pour etablir I’estimation ; 

♦ les ressources utilisees pour etablir I'estimation (comme les informations tirees de projets anterieurs similaires); 

♦ les hypotheses associees a I’estimation ; 

♦ les contraintes connues ; 

♦ la plage des estimations; 

♦ le niveau de confiance de I’estimation ; 

♦ la documentation des risques identifies ayant une influence sur I’estimation. 

9.2.3.3 ORGANIGRAMME DES RESSOURCES 

L’organigramme des ressources est une representation hierarchique des ressources par categorie et par type (voir 
la figure 9-7). Comme exemples de categories de ressources, on trouve notamment la main-d’oeuvre, le materiel, 
I'equipement et les fournitures. Les types de ressources peuvent etre le niveau de competence, le niveau hierarchique, 
les certifications requises ou toute autre information appropriee au projet. Dans le cadre du processus Planifier la 
gestion des ressources, I’organigramme des ressources a ete utilise pour guider la categorisation pour le projet. Ce 
document sera utilise pour obtenir et suivre les ressources. 
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Figure 9-7. Exemple d’organigramme des ressources 


9.2.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Attributs des activites. Ms sont decrits a la section 6.2.3.2. Les attributs des activites sont mis a jour a I’aide 
des besoins en ressources. 

♦ Registre des hypotheses. II est decrit a la section 4.1.3.2. Le registre des hypotheses est mis a jour avec 
les changements des hypotheses sur le type et la quantite de ressources necessaires. Les contraintes des 
ressources y sont egalement documentees. II s’agit notamment des conventions collectives, des heures de 
fonctionnement continu et des conges prevus. 

♦ Registre des retours d’experience. II est decrit a la section 11.2.3.1. Le registre des retours d’experience 
peut etre mis a jour avec la liste des techniques qui se sont revelees efficaces pour etablir des estimations des 
ressources, ainsi que des informations sur les techniques qui ne I’etaient pas. 
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9.3 OBTENIR LES RESSOURCES 


Obtenir les ressources est le processus qui consiste a recruter les membres de I’equipe ainsi qu’a obtenir les 
infrastructures, les equipements, le materiel, les fournitures ettoutes les autres ressources necessaires a la realisation 
des travaux du projet. L’interet principal de ce processus reside dans le fait qu’il presente et oriente la selection des 
ressources et les affecte aux differentes activites. Ce processus est execute periodiquement pendant toute la duree du 
projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 9-8. La figure 9-9 presente le diagramme de flux de donnees du processus. 


Obtenir les ressources 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
des ressources 

• Plan de gestion 

des approvisionnements 

• Reference de base 
des couts 

.2 Documents du projet 

• Echeancier du projet 

• Calendriers des ressources 

• Besoins en ressources 

• Registre des parties 
prenantes 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V___ 


1 Prise de decision 

• Analyse decisionnelle 
multicritere 

.2 Competences 

interpersonnelles et d'equipe 

• Negociation 

.3 Affectation prealable 
.4 Equipes virtuelles 
V _/ 


.1 Affectations des ressources 
materielles 

.2 Affectations des membres 
de I'equipe projet 
.3 Calendriers des ressources 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 

• Plan de gestion 
des ressources 

• Reference de base 
des couts 

.6 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Organigramme 
des ressources 

• Besoins en ressources 

• Registre des risques 

• Registre des parties 
prenantes 

.7 Mises a jour des facteurs 
environnementaux 
de I'organisation 
.8 Mises a jour des actifs 
organisationnels 

v_y 


Figure 9-8. Obtenir les ressources: donnees d’entree, outils, techniques et donnees de sortie 
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les ressources 



Plan 
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• Plan de gestion des ressources 

• Reference de base des couts 
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• Affectations des membres 
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Mises a jour des documents du projet 

• Registre des retours d’experience 
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• ; • Registre des parties prenantes 
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• Mises a jour des facteurs 
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Facteurs environnementaux 
de I’organisation 
Actifs organisationnels 


Mises a jour des actifs organisationnels 


Figure 9-9. Obtenir les ressources: diagramme de flux de donnees 


Les ressources necessaires au projet peuvent etre internes ou externes a I’organisation realisatrice. Les ressources 
internes sont obtenues, ou allouees, par les gestionnaires des ressources et les responsables fonctionnels. Les 
ressources externes sont obtenues a I'aide des processus d’approvisionnement. 

L’equipe de management de projet peut avoir ou non la martrise directe des ressources choisies, du fait de conventions 
collectives, du recours a du personnel d’un sous-traitant, d’un environnement de projet de type matriciel, des relations 
hierarchiques internes ou externes ou encore d'autres raisons. II est important que les facteurs suivants soient pris en 
consideration au cours du processus Obtenir des ressources du projet: 
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♦ le chef de projet ou I'equipe projet doivent negocier avec efficacite et influencer ceux qui sont en mesure de 
fournir les ressources materielles et de I’equipe necessaires pour le projet; 

♦ ne pas reussir a acquerir les ressources necessaires pour le projet peut avoir un impact sur les echeanciers du 
projet, les budgets, la satisfaction du client, la qualite et les risques ; une penurie de ressources ou de capacites 
se traduit par une reduction de la probabilite de reussite, voire par I’annulation du projet, dans le pire des cas ; 

♦ si les ressources de I'equipe ne sont pas disponibles en raison de contraintes, de facteurs economiques 
ou d’affectations a d’autres projets, le chef de projet ou I’equipe projet peuvent etre amenes a affecter des 
ressources alternatives, avec peut-etre des competences ou des couts differents ; les ressources alternatives 
sont autorisees sous reserve toutefois qu’il n’y ait pas d’infraction des lois, des regimentations ou d’autres 
criteres specifiques ou obligatoires. 

Ces facteurs sont a prendre en consideration lorsque le projet en est au stade de la planification. II sera demande 
au chef de projet ou a I’equipe de management de projet de documenter I'impact de I’indisponibilite des ressources 
requises dans I’echeancier, le budget, les risques et la qualite du projet, dans les plans de formation et dans les autres 
plans de management du projet. 


9.3.1 OBTENIR LES RESSOURCES : DONNEES D’ENTREE 

9.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources fournit des 
directives sur la fagon d’obtenir les ressources pour le projet. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. Le plan de gestion des 
approvisionnements contient des informations sur les ressources qui seront obtenues aupres de sources externes 
au projet. Sont comprises les informations sur I’integration des approvisionnements aux autres travaux du projet 
et aux parties prenantes qui participent a I’approvisionnement des ressources. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts fournit le 
budget global pour les activites du projet. 
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9.3.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet presente les activites avec leurs 
dates de debut et de fin prevues afin d’aider a determiner le moment ou les ressources devront etre disponibles 
et obtenues. 

♦ Calendriers des ressources. Ms sont decrits a la section 9.3.3.3. Les calendriers des ressources indiquent 
les periodes de disponibilite des ressources necessaires pour le projet. L’elaboration d’un echeancier fiable est 
tributaire d’une bonne comprehension des conflits d’echeancier et de disponibilite de chaque ressource, y compris 
les decalages horaires, les horaires de travail, les conges, l’echeancier de maintenance et les engagements sur 
d’autres projets. Les calendriers des ressources sont elabores et mis a jour de fagon progressive tout au long du 
projet. Une fois crees comme donnees de sortie de ce processus, ils seront utilises chaque fois que ce processus 
est execute. 

♦ Besoins en ressources. Ils sont decrits a la section 9.2.3.1. Les besoins en ressources identifient les ressources 
a obtenir. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes peut 
indiquer les besoins ou les attentes des parties prenantes envers des ressources specifiques a utiliser pour le 
projet qu’il convient de prendre en compte lors du processus Obtenir les ressources. 

9.3.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Obtenir les 
ressources, on peut citer: 

♦ les informations existantes sur les ressources de I'organisation, y compris la disponibilite, les niveaux de 
competence et I'experience passee pour les ressources de I’equipe et les couts des ressources; 

♦ les conditions du marche ; 

♦ la structure organisationnelle; 

♦ I’emplacement geographique. 

9.3.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Obtenir les ressources, on 
peut citer: 

♦ les politiques et les procedures en matiere d’obtention, d’allocation et d’affectation des ressources pour le projet; 

♦ les donnees historiques et I'archivage des retours d’experience. 
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9.3.2 OBTENIR LES RESSOURCES : OUTILS ET TECHNIQUES 


9.3.2.1 PRISE DE DECISION 

Elle est decrite a la section 5.2.2.4. Parmi les techniques de prise de decision qui peuvent etre utilisees lors du 
processus Obtenir les ressources figure I'analyse decisionnelle multicritere, telle que decrite a la section 8.1.2.4. Les 
criteres de selection sont souvent utilises pour selectionner les ressources materielles du projet dans le cadre de la 
constitution de I’equipe projet. L’outil d’analyse decisionnelle multicritere permet d’elaborer et d’utiliser des criteres 
visant a noter les ressources potentielles (par exemple, choisir entre les ressources internes et externes de I'equipe). 
Ces criteres sont ponderes en fonction de leur importance relative. En outre, les valeurs peuvent etre changees pour 
differents types de ressources. Voici quelques exemples de criteres de selection pouvant etre utilises : 

♦ Disponibilite. Verifier si la ressource est disponible pour travailler sur le projet pendant la periode requise. 

♦ Cout. Verifier si le cout relatif a I’ajout d’une ressource ne depasse pas le budget prescrit. 

♦ Capacite. Verifier que le membre d’equipe apporte la capacite necessaire au projet. 

Certains criteres de selection sont propres aux ressources de I'equipe : 

♦ Experience. Verifier que le membre de I’equipe possede (’experience necessaire qui contribuera a la reussite 
du projet. 

♦ Connaissances. Determiner si le membre de I’equipe connaTt le client, des projets similaires mis en oeuvre et les 
nuances de I’environnement du projet. 

♦ Competences. Determiner si le membre de I’equipe est a meme d’utiliser un outil du projet. 

♦ Comportement. Determiner si le membre de I’equipe est capable de travailler avec les autres dans une 
equipe soudee. 

♦ Facteurs internationaux. Prendre en compte le lieu, le decalage horaire et les capacites de communication du 
membre de I'equipe. 

9.3.2.2 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment 
la negociation. Elle est decrite a la section 12.2.2.5. Pour de nombreux projets, il convient de negocier les ressources 
requises. L'equipe de management de projet peut avoir a negocier avec les personnes ou entites suivantes : 

♦ Responsables fonctionnels. S’assurer que le projet regoit les meilleures ressources possible dans les delais 
impartis et jusqu’au terme de leurs responsabilites. 

♦ Autres equipes de management de projet au sein de I’organisation realisatrice. Affecter ou partager de 
maniere appropriee les ressources rares ou specialisees. 

♦ Organisations et fournisseurs externes. Fournir les ressources materielles ou de I’equipe adequates, rares, 
specialisees, qualifies, certifies ou autres. Une importance particuliere doit etre accordee aux reglements, aux 
pratiques, aux processus, aux directives, aux dispositions juridiques et a d’autres criteres de negociation externes. 
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La capacite de I’equipe de management de projet a influencer d’autres equipes joue un role important dans la 
negociation de I'allocation des ressources, tout comme la politique des organisations concernees. Par exemple, le fait de 
convaincre le responsable fonctionnel de la grande visibilite du projet peut I’inciter a affecter les meilleures ressources 
a ce projet au lieu de projets concurrents. 

9.3.2.3 AFFECTATION PREALABLE 

Lorsque les ressources materielles ou de I'equipe d’un projet sont determinees a I’avance, elles sont considerees 
comme faisant I’objet d’une affectation prealable. Cette situation peut se presenter si le projet resulte d’une identification 
de ressources specifiques dans le cadre d’une offre concurrentielle ou si le projet depend de I’expertise de certaines 
personnes. L’affectation prealable pourrait egalement inclure les membres de I’equipe qui ont deja ete affectes au 
processus Elaborer la charte du projet ou a d’autres processus avant la fin du plan de gestion des ressources. 

9.3.2.4 EQUIPES VIRTUELLES 

L’utilisation d’equipes virtuelles ouvre de nouvelles possibility lors de la constitution de I'equipe projet. Les equipes 
virtuelles peuvent etre definies comme des groupes de personnes qui partagent un meme objectif et qui remplissent 
leur role en se reunissant rarement en face a face, voire jamais. La constitution de ces equipes est rendue possible par 
I'emergence de technologies de communication, telles que le courrier electronique, les conferences audio, les medias 
sociaux, les reunions en ligne sur Internet et la videoconference. Le format d’equipe virtuelle permet: 

♦ de former des equipes de personnes de la meme organisation, residant dans des zones geographiques differentes; 

♦ d’ajouter une expertise speciale a une equipe projet, meme si I'expert ne se trouve pas dans la meme zone 
geographique; 

♦ d’incorporer des employes travaillant depuis leur domicile ; 

♦ de constituer des equipes de personnes travaillant dans des fuseaux horaires differents, en horaires ou journees 
decales; 

♦ d’incorporer des personnes en situation de handicap ou a mobilite reduite; 

♦ d’accepter des projets qui n'auraient jamais vu le jour ou qui ont ete annules en raison des frais de deplacement; 

♦ d’economiser des depenses de bureau ainsi que tous les equipements necessaires aux employes. 

La planification de la communication devient un element critique dans un environnement d’equipe virtuelle. Des 
delais supplementaires peuvent s’averer necessaires pour definir des attentes claires, faciliter les communications, 
developper des protocoles de resolution des conflits, inclure des personnes dans les prises de decision, comprendre les 
differences culturelles et partager les honneurs des succes. 


9.3.3 OBTENIR LES RESSOURCES : DONNEES DE SORTIE 

9.3.3.1 AFFECTATIONS DES RESSOURCES MATERIELLES 

La documentation des affectations des ressources materielles consigne le materiel, les equipements, les fournitures, 
les emplacements et les autres ressources materielles qui seront utilisees pendant le projet. 
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9.3.3.2 AFFECTATION DE L’EQUIPE PROJET 

La documentation des affectations de I’equipe consigne les roles et les responsabilites des membres de I’equipe 
dans le cadre du projet. Cette documentation peut comprendre un repertoire de I’equipe projet et des noms mentionnes 
dans le plan de management du projet, comme les organigrammes et les echeanciers du projet. 

9.3.3.3 CALENDRIERS DES RESSOURCES 

Le calendrier des ressources identifie les jours ouvres, les rotations d’equipe, les heures normales de travail, les fins 
de semaine et les jours feries de chaque ressource disponible. Les informations concernant les ressources, telles que 
les ressources de I’equipe, les equipements et le materiel, potentiellement disponibles pendant la conduite des activites 
prevues sont employees pour estimer I’utilisation des ressources. Les calendriers des ressources specified egalement 
quand et pour quelle duree les ressources materielles et de I’equipe identifies seront disponibles pendant le projet. 
Ces informations peuvent etre au niveau de I’activite ou du projet. Les attributs, tels que I’experience et/ou le niveau de 
competence des ressources, sont pris en compte ainsi que les differents emplacements geographiques. 

9.3.3.4 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Le chef de projet doit deposer une demande pour tout changement apporte 
durant le processus Obtenir les ressources (par exemple, les impacts sur I’echeancier) ou lorsque des actions preventives 
ou correctives recommandees ont une incidence sur I’un des composants du plan de management du projet ou les 
documents du projet. Les demandes de changement sont passees en revue et traitees par le processus Maitriser les 
changements (voir la section 4.6). 

9.3.3.5 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I’organisation par I’intermediaire d’une demande de changement. Les elements du plan de management du projet qui 
sont susceptibles d’etre mis a jour suite a I'execution de ce processus sont notamment les suivants : 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources peut 
etre mis a jour pour refleter I’experience acquise lors de I’obtention des ressources du projet. Ceci comprend 
notamment les retours d’experience sur I'obtention des ressources en debut de projet et revolution des besoins 
de recrutement au fur et a mesure de I’execution. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts peut changer 
suite a I’obtention de ressources pour le projet. 
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9.3.3.6 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour avec les difficulty rencontrees pour I’obtention des ressources et les moyens pour les eviter, ainsi que sur 
les approches qui ont bien fonctionnees. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. Les changements apportes a I'echeancier du projet 
peuvent resulter de la disponibilite des ressources requises. 

♦ Organigramme des ressources. II est decrit a la section 9.2.3.3. Les ressources obtenues pendant ce processus 
sont consignees dans I’organigramme des ressources. 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. La documentation des exigences en matiere de 
ressources est mise a jour afin de refleter les ressources obtenues pour le projet. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1 . Le registre des parties prenantes est mis a 
jour avec soit des nouvelles parties prenantes, soit de nouvelles informations concernant des parties prenantes 
existantes qui ont ete obtenues grace a ce processus. 

9.3.3.7 MISES A JOUR DES FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui sont mis a jour, on peut citer: 

♦ la disponibilite des ressources au sein de I’organisation ; 

♦ la quantite de consommables de I’organisation qui a ete utilisee. 

9.3.3.8 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui sont mis a jour suite au processus Obtenir les ressources figure notamment la 
documentation relative a I’obtention, a I'allocation et a I'affectation des ressources. 
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9.4 DEVELOPPER L’EQUIPE 


Developper I'equipe est le processus qui consiste a ameliorer les competences des membres de I'equipe, leurs 
interactions et I’environnement global de I’equipe, afin d’ameliorer la performance du projet. L’interet principal de ce 
processus reside dans le fait qu’il se traduit par un meilleur travail d’equipe, une mise en valeur des competences 
interpersonnelles, des employes motives, une reduction du taux de rotation du personnel et une amelioration globale 
des performances du projet. Ce processus est execute tout au long du projet. 

Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 9-10. La figure 9-11 presente le diagramme de flux de donnees du processus. 


Developper I’equipe 


Donnees d’entree M Outils et techniques ■ Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
des ressources 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Affectations des membres 
de I'equipe projet 

• Calendriers des ressources 

• Charte d'equipe 

.3 Facteurs environnementaux 

de I'organisation 

.4 Actifs organisationnels 

V___ J 


.1 Colocalisation 
.2 Equipes virtuelles 
.3 Technologie 
de communication 
.4 Competences 

interpersonnelles et d'equipe 

• Gestion des conflits 

• Influence 

• Motivation 

• Negociation 

• Developpement de I'esprit 
d'equipe 

.5 Reconnaissance et 
recompenses 
.6 Formation 

.7 Evaluations des personnes 
et de I'equipe 
.8 Reunions 

V_y 


1. Evaluations des performances 
de I'equipe 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 

• Plan de gestion 
des ressources 

.4 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Affectations des membres 
de I'equipe projet 

• Calendriers des ressources 

• Charte d'equipe 

.5 Mises a jour des facteurs 
environnementaux 
de I'organisation 
.6 Mises a jour des actifs 
organisationnels 

V_ J 


Figure 9-10. Developper I’equipe : donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


Plan de management du projet 
• Plan de gestion des ressources 


Documents du projet 

• Registre des retours d’experience 

• Echeancier du projet 

• Affectations des membres 
de I’equipe projet 

• Calendriers des ressources 

• Charte d’equipe 


Entreprise/ 

Organisation 


Evaluations des performances 
de I’equipe 


9.5 

Gerer 

I’equipe 


Demandes de changement 


4.6 

Effectuer 

la gestion integree 
des changements 


Documents 




9.4 


du projet 




I'equipe 



Plan 

de management 
du projet 


Mises a jour du plan 
de management du projet 
• Plan de gestion des ressources 


Facteurs environnementaux 
de I’organisation 
Actifs organisationnels 


Mises a jour des documents du projet 

• Registre des retours d’experience 

• Echeancier du projet 

• Affectations des membres 
de I’equipe projet 

• Calendriers des ressources 

• Charte d’equipe 


Mises a jour des facteurs 
environnementaux de I’organisation 
Mises a jour des actifs organisationnels 


Documents 
du projet 


Entreprise/ 

Organisation 


Figure 9-11. Developper I’equipe: diagramme de flux de donnees 


Les chefs de projet doivent etre competents pour identifier, constituer, entretenir, motiver, guider et inspirer les equipes 
projet en vue d’atteindre de hautes performances et de realiser les objectifs du projet. Le travail d’equipe est un facteur 
critique pour la reussite du projet, et developper des equipes projet efficaces est I’une des responsabilites majeures 
du chef de projet. Les chefs de projet doivent creer un environnement favorable au travail d’equipe et continuellement 
motiver leur equipe par des defis et des opportunites, en fournissant regulierement des retours d’information et 
I'accompagnement necessaire, tout en reconnaissant et en recompensant les bonnes performances. Pour atteindre une 
haute performance de I'equipe, il faut: 

♦ avoir une communication ouverte et efficace; 

♦ creer des opportunites de developpement de I’esprit d’equipe ; 

♦ developper la confiance entre les membres de I’equipe ; 

♦ gerer les conflits de fagon constructive; 

♦ encourager une resolution des problemes; 

♦ encourager une prise de decision de type collaboratif. 
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Les chefs de projet evoluent dans un environnement global et travaillent sur des projets caracterises par la diversite 
culturelle. Les membres de I’equipe ont souvent des experiences dans des secteurs divers, parlent differentes langues 
et travaillent parfois dans une « langue de travail » ou selon une norme culturelle qui peut etre differente de leur 
langue ou de leur norme d’origine. L’equipe de management de projet doit mettre a profit les differences culturelles, se 
concentrer sur le developpement et I’accompagnement de I'equipe projet tout au long du cycle de vie du projet mais 
aussi promouvoir le travail collaborate dans un climat de confiance. Developper I'equipe projet ameliore le contact, 
les competences techniques, I'environnement de I'ensemble de I'equipe et la performance du projet. Ceci exige une 
communication claire, en temps opportun et efficace entre les membres de I'equipe pendant toute la duree du projet. 
Parmi les objectifs de developpement d’une equipe projet, on peut citer: 

♦ ameliorer les connaissances et les competences des membres de I’equipe afin d’augmenter leur capacite a 
produire les livrables du projet tout en reduisant les couts, en raccourcissant les echeanciers et en ameliorant 
la qualite; 

♦ ameliorer le sentiment de confiance et de cohesion chez les membres de I'equipe dans le but de renforcer le 
moral, de reduire les conflits et d’encourager le travail d’equipe ; 

♦ creer une culture d’equipe dynamique, coherente et collaborative dans le but de: (1) renforcer a lafois la productivite 
individuelle et d’equipe, I’esprit d’equipe et la cooperation et (2) permettre la formation interdisciplinaire et le 
tutorat entre les membres de I’equipe de fagon a partager les connaissances et I'expertise ; 

♦ donner les moyens a I’equipe projet de participer a la prise de decision et de s’approprier les solutions offertes 
afin d’ameliorer la productivite de I'equipe et d’obtenir de meilleurs resultats. 

L'un des modeles utilises pour decrire le developpement de I'esprit d’equipe est I’echelle de Tuckman (19, 20) 
composee de cinq etapes de developpement. Bien que ces etapes se produisent souvent dans I'ordre, il n’est pas rare 
pour une equipe de rester bloquee dans une etape specifique ou de retomber dans une etape precedente. De meme, on 
pourrait sauter une etape pour des projets dont les membres de I'equipe ont deja travaille ensemble. 

♦ Formation (Forming). C’est la phase au cours de laquelle les membres de I’equipe se reunissent et se renseignent 
sur le projet et sur les roles et les responsabilites officiels de chacun. Pendant cette phase, les membres de 
I'equipe ont tendance a etre independants et plus renfermes. 

♦ Turbulence (Storming). Au cours de cette phase, I'equipe commence a traiter le travail du projet, a examiner 
les decisions techniques et a definir I’approche du management de projet. Si les membres de I'equipe ne 
travaillent pas dans un esprit de collaboration ou ne sont pas ouverts a des idees et perspectives divergentes, cet 
environnement peut devenir destructeur. 

♦ Normalisation (Norming). Au cours de cette phase, les membres de I'equipe commencent a travailler ensemble 
et adaptent leurs habitudes et comportements de travail au service de I’equipe. La confiance s’instaure au sein 
de I'equipe. 

♦ Performance (Performing). Les equipes qui parviennent a ce stade fonctionnent comme des unites bien 
organisees. Elies sont interdependantes et font face aux problemes de fagon posee et efficace. 

♦ Dissolution (Adjourning). Au cours de cette phase, I'equipe acheve le travail et se desengage du projet. Cette 
situation apparait generalement lorsque le personnel est demobilise du projet suite a I’achevement des livrables 
ou dans le cadre du processus Clore le projet ou la phase. 
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La duree d’une etape particuliere depend de la dynamique, de la taille et de la conduite de I'equipe. Les chefs de 
projet doivent avoir une bonne comprehension de la dynamique d’equipe pour accompagner les membres de I’equipe a 
travers toutes les etapes d’une fagon efficace. 


9.4.1 DEVELOPPER L’EQUIPE : DONNEES D’ENTREE 

9.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le plan 
de gestion des ressources. Decrit a la section 9.1.3.1, ce plan fournit des indications concernant les recompenses, les 
remarques, les formations complementaires et les mesures disciplinaires a regard des membres de I’equipe projet suite 
aux evaluations de performance de I’equipe et a d'autres formes de gestion de I’equipe projet. II peut egalement inclure 
les criteres devaluation de la performance de I’equipe. 

9.4.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du 
projet concernant le developpement d’equipe peuvent etre appliques aux phases ulterieures pour ameliorer la 
performance de I’equipe. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet definit comment et quand former 
I'equipe projet et perfectionner les competences necessaires aux differentes phases. II identifie la necessity 
d’elaborer des strategies de developpement de I’equipe en fonction des ecarts, le cas echeant, durant I'execution 
du projet. 

♦ Affectations des membres de i’equipe projet. Elies sont decrites a la section 9.3.3.1. Les affectations des 
membres de I’equipe projet identifient les roles et les responsabilites des membres de I’equipe. 

♦ Calendriers des ressources. Ms sont decrits a la section 9.2.1.2. Les calendriers des ressources identifient 
les periodes auxquelles les membres de I’equipe projet sont disponibles pour prendre part aux activites de 
developpement de I’equipe. Ms permettent egalement d’indiquer la disponibilite de I’equipe tout au long du projet. 

♦ Charte d’equipe. Elle est decrite a la section 9.1.3.2. La charte d’equipe documente les directives de 
fonctionnement de I’equipe. Les valeurs et les directives de fonctionnement de I’equipe structurent la fagon dont 
les membres de I’equipe fonctionneront ensemble. 

9.4.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Developper 
I’equipe, on peut citer: 

♦ les politiques de gestion des ressources humaines en matiere de recrutement et de licenciement, de revues de 
performance des employes, de dossiers de formation et de developpement du personnel et de reconnaissance 
etde recompenses; 

♦ les competences et les connaissances specialisees des membres de I’equipe; 

♦ la distribution geographique des membres de I'equipe. 
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9.4.1.4 ACTIFS ORGANISATION ELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Developper I’equipe figurent 
notamment les donnees historiques et I’archivage des retours d’experience. 


9.4.2 DEVELOPPER L’EQUIPE : OUTILS ET TECHNIQUES 

9.4.2.1 COLOCALISATION 

La colocalisation consiste a rassembler au meme endroit un grand nombre des membres les plus actifs de I’equipe 
projet, voire tous, afin d'ameliorer leur capacite a travailler en equipe. La colocalisation peut etre provisoire, comme 
durant des periodes strategiquement importantes au cours du projet, ou concerner I’ensemble du projet. Les strategies 
de colocalisation peuvent comprendre une salle de reunions pour I’equipe, des parties communes pour afficher les 
echeanciers et d’autres equipements destinees a ameliorer la communication et le sentiment de communaute. 

9.4.2.2 EQUIPES VIRTUELLES 

Les equipes virtuelles peuvent presenter des avantages, comme (’utilisation de ressources plus competentes, la 
reduction des couts de deplacements et des frais de demenagement, et le rapprochement des membres de I’equipe 
et des fournisseurs, des clients ou d’autres parties prenantes cles. Les equipes virtuelles peuvent mettre a profit la 
technologie pour creer un espace de travail en ligne ou elles peuvent stacker des fichiers, utiliser des fils de conversation 
pour aborder les points a traiter et tenir un calendrier d’equipe. 

9.4.2.3 TECHNOLOGIE DE COMMUNICATION 

Elle est decrite a la section 10.1.2.3. La technologie de communication joue un role important dans la resolution des 
problemes de developpement des equipes virtuelles et colocalisees. Elle aide a creer un environnement harmonieux pour 
I’equipe colocalise et une meilleure collaboration pour I’equipe virtuelle, notamment pour les equipes avec decalages 
horaires. Parmi les exemples de technologie de communication, on peut citer les suivantes: 

♦ Portail commun. Le systeme d’archivage commun dedie au partage des informations (par exemple, un site 
Web, un logiciel de collaboration ou un intranet) est un outil efficace pour les equipes projet virtuelles. 

♦ Videoconference. La videoconference est une technique importante pour une communication efficace entre les 
equipes virtuelles. 

♦ Conferences audio. Les conferences audio sont une autre technique de communication avec I’equipe qui 
permet d’etablir des liens et une confiance au sein des equipes virtuelles. 

♦ Courrier electronique et messagerie instantanee. Les communications regulieres par courrier electronique 
ou messagerie instantanee sont egalement efficaces. 
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9.4.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 


Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Gestion des conflits. Elle est decrite a la section 9.5.2.1. Le chef de projet doit resoudre les conflits en temps 
opportun et constructive pour avoir une equipe performante. 

♦ Influence. Elle est decrite a la section 9.5.2.1. La capacite d’influence est utilisee pour collecter des informations 
pertinentes et critiques afin de resoudre les points a traiter importants et conclure des accords tout en preservant 
une confiance reciproque 

♦ Motivation. La motivation donne a quelqu’un une raison d’agir. Les equipes sont motivees lorsqu’elles ont la 
possibility de participer a la prise de decision et sont encouragees a travailler de fagon independante. 

♦ Negociation. Elle est decrite a la section 12.2.2.5. La negociation au sein des membres d’une equipe permet de 
parvenir a un consensus sur les besoins du projet. La negociation instaure un climat de confiance et d’harmonie 
au sein des membres de I’equipe. 

♦ Developpement de I’esprit d’equipe. Le developpement de I’esprit d’equipe consiste a mener des activites 
qui renforcent les relations sociales de I’equipe et creent un environnement de travail collaboratif et cooperatif. 
Les activites de developpement de I'esprit d’equipe peuvent varier, depuis un sujet aborde en cinq minutes au 
cours d’une reunion de revue d’avancement, jusqu'a un seminaire organise a I’exterieur par des professionnels, 
ayant pour but d’ameliorer les relations interpersonnelles. L'objectif des activites de developpement de I'esprit 
d’equipe est d’aider les membres individuels de I’equipe a travailler ensemble de fagon efficace. Les strategies 
de developpement de I’esprit d’equipe sont particulierement utiles lorsque les membres de I’equipe travaillent 
dans des emplacements distants, sans les avantages du contact en face a face. La communication et les activites 
informelles peuvent contribuer a instaurer un climat de confiance et a etablir de bonnes relations de travail. Bien 
que le developpement de I'esprit d’equipe soit essentiel dans les phases initiales d’un projet, ce processus doit 
etre continu. Les changements sont inevitables dans I’environnement d’un projet. II est necessaire de developper, 
de soutenir ou de renouveler I’esprit d’equipe pour les gerer efficacement. Le chef de projet doit suivre en 
permanence le fonctionnement et la performance de I'equipe afin de determiner si des actions sont necessaires 
pour prevenir ou corriger differents problemes au sein de I'equipe. 

9.4.2.5 RECONNAISSANCE ET RECOMPENSES 

Une partie du processus de developpement de I’equipe consiste a reconnaitre et a recompenser un comportement 
souhaitable. Le plan de recompenses initial est elabore lors du processus Planifier la gestion des ressources. Une 
recompense est uniquement efficace lorsqu'elle satisfait un besoin important pour la personne concernee. Les 
decisions de recompense sont prises, de maniere formelle ou informelle, dans le cadre du processus de gestion 
de I’equipe projet. Les differences culturelles doivent etre prises en compte pour determiner la reconnaissance et 
les recompenses. 
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Les personnes sont motivees si elles se sentent estimees dans I’organisation, et cette estime est materialisee par les 
recompenses qui leur sont donnees. En regie generate, I’argent est pergu par la plupart comme un aspect tangible de 
tout systeme de recompense, mais d’autres recompenses intangibles sont tout aussi efficaces, sinon plus. La plupart des 
membres de I’equipe projet sont motives par une opportunity de progresses de s’accomplir, d’etre apprecie et de mettre 
en pratique leurs competences professionnelles pour relever de nouveaux defis. Une bonne strategic pour les chefs de 
projet consiste a accorder a I’equipe une reconnaissance tout au long du cycle de vie du projet au lieu d’en attendre. 

9.4.2.6 FORMATION 

La formation comprend toutes les activites destinees a ameliorer les competences des membres de I’equipe projet. 
Elle peut etre formelle ou informelle. Parmi les exemples de methodes de formation, on peut citer la formation en 
salle de classe, en ligne/e-learning, sur le lieu de travail avec I'aide d’un autre membre de I’equipe projet, le tutorat 
et I'accompagnement. Si les membres de I’equipe projet ne disposent pas des competences en management ou des 
techniques necessaires, ces competences peuvent etre developpees dans le cadre du travail du projet. La formation 
planifiee se deroule conformement au plan de gestion des ressources. La formation non planifiee est le resultat d’une 
observation, d’une conversation et des evaluations de la performance du projet, effectuees au cours du processus 
de gestion de I'equipe projet. Les couts de formation peuvent etre inclus dans le budget du projet, ou supportes par 
I'organisation realisatrice, si ces competences additionnelles sont utiles pour de futurs projets. Cette formation peut etre 
dispensee par des formateurs internes ou externes. 

9.4.2.7 EVALUATIONS DES PERSONNES ET DE L’EQUIPE 

Les outils devaluation des personnes et de I’equipe donnent au chef de projet, et a I’equipe projet, une vue precise des 
points forts et des points faibles. Grace a ces outils, les chefs de projet peuvent non seulement evaluer les preferences 
et les aspirations des membres de I’equipe, mais aussi leur fagon de traiter et d’organiser les informations, de prendre 
des decisions et d’interagir avec les autres. II existe divers outils tels que les sondages attitudinaux, les evaluations 
specifiques, les entretiens structures, les tests d’aptitude et les groupes de discussion. Ces outils permettent d’ameliorer 
la comprehension, la confiance, I’engagement et la communication au sein de I'equipe, et d’augmenter la productivity 
des equipes au fil du projet. 

9.4.2.8 REUNIONS 

Les reunions permettent d’aborder et de traiter les sujets pertinents pour developper I’equipe. Les participants sont 
le chef de projet et I'equipe projet. Ces reunions incluent notamment les reunions d’orientation, de cohesion et de 
developpement de I’equipe. 
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9.4.3 DEVELOPPER L’EQUIPE : DONNEES DE SORTIE 


9.4.3.1 EVALUATION DES PERFORMANCES DE L’EQUIPE 

A mesure que les efforts de developpement de I’equipe projet, tels que la formation, le developpement de I'esprit 
d’equipe et la colocalisation sont fournis, I'equipe de management de projet effectue des evaluations formelles et 
informelles de I’efficacite de I'equipe projet. Des strategies et des activites efficaces de developpement de I’equipe sont 
supposees accroTtre sa performance, augmentantainsi la probability d’atteindre les objectifs du projet. 

Devaluation de I’efficacite d’une equipe peut inclure des indicateurs suivants: 

♦ amelioration des capacites, qui permet aux personnes d’effectuer plus efficacement les activites qui leur sont 
attributes; 

♦ amelioration des competences qui permettent aux membres de I’equipe de mieux fonctionner; 

♦ reduction du taux de rotation des ressources humaines ; 

♦ plus de cohesion de I’equipe lorsque ses membres partagent ouvertement les informations et les experiences, 
et s'entraident pour ameliorer les performances globales du projet. 

A Tissue d’une evaluation de la performance globale de I'equipe, I’equipe de management de projet peut identifier les 
besoins de formation, d’accompagnement, de tutorat, d’assistance ou de changements pour ameliorer la performance 
de I’equipe. Cela doit aussi inclure Tidentification des ressources appropriees ou requises pour mettre en oeuvre des 
ameliorations identifies dans le cadre de revaluation. 

9.4.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Le chef de projet doit deposer une demande de changement et suivre le 
processus MaTtriser les changements defini a la section 4.6 pour toute demande de changement suite au processus 
Developper I’equipe ou lorsque des actions preventives ou correctives recommandees ont une incidence sur Tun des 
composants du plan de management du projet ou les documents du projet. 

9.4.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de Torganisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, figure le plan de gestion des ressources decrit a la 
section 9.1.3.1. 
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9.4.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est 
mis a jour a I’aide des informations sur les difficulty rencontrees pour developper I'equipe et les moyens pour 
les eviter, ainsi que sur les approches qui ont bien fonctionne. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. Les activites pour developper I’equipe projet peuvent 
entrainer des changements au niveau de I’echeancier du projet. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.1. Si des changements sont 
apportes aux affectations convenues suite au developpement de I’equipe, ces changements sont consignes dans 
la documentation des affectations de I'equipe projet. 

♦ Calendriers des ressources. Ms sont decrits a la section 9.2.1.2. Les calendriers des ressources sont mis a jour 
afin de refleter la disponibilite des ressources du projet. 

♦ Charte d’equipe. Elle est decrite a la section 9.1.3.2. La charte d’equipe peut etre mise a jour afin de refleter 
les changements apportes aux directives de fonctionnement convenues de I’equipe qui resultent de son 
developpement. 

9.4.3.5 MISES A JOUR DES FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui sont mis a jour suite au processus Developper I’equipe 
projet, on peut citer: 

♦ les dossiers des plans de developpement du personnel; 

♦ les evaluations des competences. 

9.4.3.6 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui sont mis a jour suite au processus Developper I’equipe projet, on peut citer: 

♦ les exigences de formation ; 

♦ revaluation du personnel. 
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9.5 GERER L’EQUIPE 


Gerer I'equipe est le processus qui consiste a suivre la performance des membres de I’equipe, a fournir des 
remarques, a resoudre des points a traiter et a gerer des changements dans I’equipe pour optimiser la performance du 
projet. L’interet principal de ce processus est qu'il permet d’influencer le comportement de I'equipe, de gerer les conflits 
et de resoudre les points a traiter. Ce processus est execute tout au long du projet. 

Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 9-12. La figure 9-13 presente le diagramme de flux de donnees du processus. 




.2 Documents du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Affectations des membres 
de I'equipe projet 

• Charte d'equipe 


.1 Plan de management du projet 
• Plan de gestion 
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• Reference de base 
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d'execution 
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de gestion du projet (Project 
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.3 Mises a jour des documents 
du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Affectations des membres 
de I'equipe projet 
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de I'equipe 


.5 Facteurs environnementaux 
de I'organisation 


.6 Actifs organisationnels 


.4 Mises a jour des facteurs 
environnementaux 
de I'organisation 


V 


Figure 9-12. Gerer I’equipe: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 9-13. Gerer I’equipe : diagramme de flux de donnees 


Diriger I’equipe projet exige une serie de competences en management et en leadership pour encourager le travail 
d’equipe et integrer les efforts des membres de I’equipe, afin de creer des equipes hautement performantes. La gestion 
d’equipe requiert une combinaison de competences mettant en exergue tout particulierement la communication, la 
gestion des conflits, la negociation et le leadership. Les chefs de projet doivent proposer aux membres de I’equipe des 
taches stimulantes et recompenser les bonnes performances. 

Le chef de projet doit faire attention a la volonte et a la capacite dont les membres de I'equipe font preuve pour 
executer leurs taches et adapter leurs styles de gestion et de leadership en consequence. Les membres peu qualifies 
de I'equipe devront faire I’objet d’une plus grande supervision que ceux ayant demontre leurs capacites et experience. 
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9.5.1 GERER L’EQUIPE : DONNEES D’ENTREE 


9.5.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le plan 
de gestion des ressources. Decrit a la section 9.1.3.1, le plan de gestion des ressources fournit des instructions sur la 
fagon dont les ressources de I’equipe projet doivent etre gerees et, finalement, desengagees. 

9.5.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des points a traiter. II est decrit a la section 4.3.3.3. Des points a traiter surviennent lors de la gestion 
d’une equipe projet. Un registre des points a traiter peut servir pour documenter et suivre qui est responsable de 
la resolution des points a traiter specifiques a une date cible. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer I’efficacite de la gestion de I’equipe. 

♦ Affectations des membres de i’equipe projet. Elies sont decrites a la section 9.3.3.1. Les affectations des 
membres de I’equipe projet identifient les roles et les responsabilites des membres de I’equipe. 

♦ Charte d’equipe. Elle est decrite a la section 9.1.3.2. La charte d’equipe fournit des instructions sur la fagon dont 
I’equipe peut prendre des decisions, conduire des reunions et resoudre des conflits. 

9.5.1.3 RAPPORTS SUR LA PERFORMANCE D’EXECUTION 

lls sont decrits a la section 4.5.3.1. Les rapports sur la performance d’execution sont une representation papier ou 
electronique de I’information sur la performance du travail destinee a generer des prises de decision, des actions ou 
une sensibilisation. Les rapports sur la performance peuvent aider a la gestion de I'equipe projet lorsqu’ils comprennent 
les resultats de la maTtrise de I’echeancier, des couts et de la qualite mais aussi de la validation du perimetre. Les 
informations provenant des rapports d’avancement et les previsions connexes, aident a determiner les besoins futurs de 
I’equipe en ressources, la reconnaissance et les recompenses ainsi que les mis a jour du plan de gestions des ressources. 

9.5.1.4 EVALUATIONS DES PERFORMANCES DE L’EQUIPE 

Elies sont decrites a la section 9.4.3.1. L’equipe de management de projet precede a des evaluations formelles ou 
informelles des performances de I'equipe projet. Grace a cette evaluation en continu des performances de I'equipe de 
projet, des actions peuvent etre engagees pour resoudre des points a traiter, changer la communication, traiter des 
conflits et ameliorer la collaboration au sein de I'equipe. 
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9.5.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Gerer 
Pequipe, on peut citer les politiques de gestion des ressources humaines. 

9.5.1.6 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Gerer I’equipe, on peut citer: 

♦ les certificats depreciation ; 

♦ les produits portant le sigle de I'organisation ; 

♦ d’autres avantages proposes par ^organisation. 

9.5.2 GERER L’EQUIPE : OUTILS ET TECHNIQUES 

9.5.2.1 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Gestion des conflits. Les conflits sont inevitables dans un environnement de projet. Les sources de conflit 
comprennent la rarete des ressources, les priorites de I’echeancier et les styles de travail de chacun. Des regies 
de base pour I’equipe, des normes de groupe, et des pratiques solides en management de projet, comme la 
planification des communications et la definition des roles, reduisent le nombre de conflits. 

Une gestion des conflits reussie se traduit par une meilleure productivity et des relations de travail positives. 
Bien gerees, les differences d’opinion peuvent aboutir a une plus grande creativity et a une meilleure prise de 
decision. Si les differences deviennent un facteur negatif, il appartient avant tout aux membres de I’equipe 
projet de les resoudre. Si le conflit s'aggrave, le chef de projet doit s'impliquer pour amener a une resolution 
satisfaisante. Le conflit doit etre traite au plus tot, et generalement en prive, par une approche directe et 
collaborative. Si un conflit non constructif persiste, il peut etre necessaire de recourir a des procedures formelles, 
y compris des mesures disciplinaires. 

Le succes des chefs de projet dans la direction de leurs equipes projet depend souvent de leur capacity a 
resoudre les conflits. Differents chefs de projet peuvent avoir differentes methodes de resolution des conflits. Les 
facteurs qui influencent les methodes de resolution de conflits comprennent: 

■ I'importance et I’intensite du conflit; 

■ la pression du temps pour resoudre le conflit; 

■ le pouvoir relatif des personnes impliquees dans le conflit; 

■ I'importance de maintenir une bonne relation ; 

■ la motivation pour resoudre le conflit pour le court ou le long terme. 
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II existe cinq techniques globales de resolution des conflits, chacune d'elles s'utilisant de fagon adequate. 

o Retrait/evitement. Se retirer d’une situation de conflit reelle ou potentielle; reporter a plus tard le differend 
pour mieux s'y preparer ou pour en confier la resolution a d’autres personnes. 
o Acceptation/accommodement. Mettre en avant les points d’accord plutot que les differences; conceder la 
position d’une personne pour les besoins des autres afin de maintenir I’harmonie et les relations, 
o Compromis/conciliation. Rechercher des solutions qui apportent un certain degre de satisfaction a toutes 
les parties afin de resoudre partiellement ou temporairement le conflit. Cette approche cree parfois une 
situation du type perdant-perdant. 

o Force/competition. Imposer son point de vue au detriment d’autres se traduit par des solutions du type 
gagnant-perdant generalement mises en place par le biais d’une position de pouvoir pour resoudre une 
situation d’urgence. Cette approche cree souvent une situation du type gagnant-perdant. 
o Collaboration/resolution de problemes. Integrer des points de vue et des visions multiples a partir de 
differentes perspectives; cela necessite une cooperation et un dialogue ouvert qui menent generalement 
au consensus et a I'engagement. Cette approche peut creer une situation du type gagnant-gagnant. 

♦ Prise de decision. Dans ce contexte, la prise de decision fait appel a la capacite de negocier et d'influencer 
I’organisation et I'equipe de management de projet, plutot que I’ensemble des outils decrits dans pour prise de 
decision. Voici des exemples de recommandations en matiere de prise de decision : 

■ se concentrer sur les objectifs vises; 

■ suivre un processus de prise de decision ; 

■ etudier les facteurs environnementaux; 

■ analyser les informations disponibles; 

■ encourager la creativite de I'equipe; 

■ tenir compte les risques. 

♦ Intelligence emotionnelle. [.'intelligence emotionnelle est la capacite d’identifier, d’evaluer, de gerer ses 
emotions personnels et celles d'autres personnes, aussi bien que les emotions collectives de groupes 
de personnes. L'equipe peut utiliser [intelligence emotionnelle pour attenuer les tensions et ameliorer la 
cooperation en identifiant, evaluant et martrisant I’etat d’esprit des membres de I’equipe projet, en anticipant 
leurs actions, en prenant en compte leurs soucis et en les assistant en cas de probleme. 
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♦ Influence. Etant donne que les chefs de projet n’ont souvent que tres peu ou pas d’autorite directe sur les 
membres de leur equipe dans un environnement matriciel, leur capacite d’influencer les parties prenantes au 
moment opportun s’avere critique pour le succes du projet. Les competences cles permettant d’influencer les 
autres comprennent: 

■ la capacite de persuader; 

■ la capacite d’exprimer clairement des avis et des points de vue ; 

■ de hauts niveaux de capacite d’ecoute active et efficace; 

■ la connaissance et la prise en compte de differentes perspectives dans toute situation ; 

■ la collecte d'informations pertinentes pour resoudre les points a traiter et conclure des accords tout en 
preservant une confiance reciproque. 

♦ Leadership. Les projets couronnes de succes exigent des chefs dotes de fortes competences en leadership. 
Le leadership designe la capacite a diriger une equipe et a la motiver a bien faire son travail. Cette competence 
englobe un vaste eventail d’aptitudes, de capacites et d’actions. Le leadership est important a travers toutes 
les phases du cycle de vie du projet. II existe plusieurs theories du leadership, chacune definissant les styles de 
leadership a adopter suivant la situation ou I’equipe. II est particulierement important de communiquer la vision 
et d’inspirer I’equipe projet dans le but d’atteindre les meilleures performances. 

9.5.2.2 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Le systeme d'information de management du projet peut inclure le logiciel de 
planification ou de gestion des ressources permettant de gerer et de coordonner les membres de I'equipe lors des 
activites du projet. 


9.5.3 GERER L’EQUIPE : DONNEES DE SORTIE 

9.5.3.1 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Le chef de projet doit deposer une demande pour tout changement apporte 
durant le processus Gerer I'equipe ou lorsque des actions preventives ou correctives recommandees ont une incidence 
sur I’un des composants du plan de management du projet ou les documents du projet. Les demandes de changement 
sont passees en revue et traitees par le processus MaTtriser les changements (voir la section 4.6). 

Par exemple, les changements des effectifs, suite a des choix ou des evenements que I’on ne peut pas controler, 
peuvent perturber I’equipe projet. Ceci peut entrainer des delais ou un depassement de budget. Les changements des 
effectifs incluent, par exemple, I’affectation des personnes a des taches differentes, I'externalisation d’une partie du 
travail ou le remplacement des membres de I’equipe ayant decide de partir. 
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9.5.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants du plan de management 
du projet qui peuvent exiger une demande de changement pour le plan de management du projet, on peut citer les 
elements suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources est mis a 
jouravec I’experience pratique en matiere de gestion de I'equipe projet. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. L’echeancier du projet peut necessiter 
des changements lies aux performances de I'equipe. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts peut necessiter 
des changements lies aux performances de I'equipe. 

9.5.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les nouveaux points a traiter souleves suite a ce 
processus sont consignes dans le registre correspondant. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour avec les informations sur les difficulty rencontrees de gestion de I’equipe, les moyens pour les eviter et 
les approches qui ont bien fonctionne. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.1. Si I’equipe necessite des 
changements, ils doivent etre consignes dans la documentation des missions des membres de I’equipe projet. 

9.5.3.4 MISES A JOUR DES FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui sont mis a jour suite au processus Gerer I’equipe, on 
peut citer: 

♦ les donnees d’entree pour les evaluations des performances de I’organisation ; 

♦ les competences personnels. 
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9.6 MAITRISER LES RESSOURCES 

MaTtriser les ressources est le processus qui consiste a s’assurer de la disponibilite des ressources allouees au projet, 
conformement aux previsions, a en suivre I’utilisation reelle par rapport aux previsions et a mettre en place des actions 
correctives, le cas echeant. L'interet principal de ce processus reside dans le fait qu’il veille a ce que les ressources 
affectees soient mises a la disposition du projet au bon moment et au bon endroit, et qu’elles soient liberees des qu'elles 
ne sont plus necessaires. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce 
processus sont presentees a la figure 9-14. La figure 9-15 presente le diagramme de flux de donnees du processus. 


Maitriser les ressources 


Donnees d’entree V Outils et techniques V Donnees de sortie 


.1 Plan de management du projet 

• Plan de gestion 
des ressources 

.2 Documents du projet 

• Journal des points a trader 

• Registre des retours 
d'experience 

• Affectations des ressources 
materielles 

• Echeancier du projet 

• Organigramme 
des ressources 

• Besoins en ressources 

• Registre des risques 

.3 Donnees de performance 

d'execution 

.4 Accords 

.5 Actifs organisationnels 
V___ 


.1 Analyse des donnees 

• Analyse des alternatives 

• Analyse cout-benefice 

• Revues de performance 

• Analyse de la tendance 
.2 Resolution de problemes 
.3 Competences 

interpersonnelles et d'equipe 

• Negociation 

• Influence 

.4 Systeme d’information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

V___ 


.1 Information sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 

de management du projet 

• Plan de gestion 
des ressources 

• Reference de base 
de 1'echeancier 

• Reference de base 
des couts 

.4 Mises a jour des documents 

du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Affectations des ressources 
materielles 

• Organigramme 
des ressources 

• Registre des risques 

v ___/ 


Figure 9-14. Maitriser les ressources : donnees d’entree, outils, techniques et donnees de sortie 
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Figure 9-15. Maitriser les ressources: diagramme de flux de donnees 


Le processus Maitriser les ressources doit etre execute lors de toutes les phases du projet mais aussi tout au long du 
cycle de vie du projet. Les ressources necessaires au projet doivent etre affectees et desengagees de fagon adequate 
afin que le projet puisse se poursuivre sans delais. Le processus Maitriser les ressources concerne les ressources 
materielles, comme I’equipement, le materiel, les installations et I’infrastructure. Les membres de I’equipe font partie 
du processus Gerer I’equipe. 

Les techniques de maTtrise des ressources discutees dans cette section sont celles le plus frequemment utilisees 
dans les projets. II en existe beaucoup d’autres qui peuvent etre utiles pour certains projets ou dans certains domaines 
d’application. 
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Lors de la mise a jour de I’allocation des ressources, il convient de savoir quelles ressources ont ete utilisees a ce 
jour et lesquelles sonttoujours requises. Cela consiste principalement a passer en revue I’utilisation des performances 
a la date concernee. Le processus MaTtriser les ressources concerne: 

♦ le suivi des depenses en ressources; 

♦ I’identification et la gestion opportunes des penuries/surplus de ressources ; 

♦ la garantie que les ressources sont utilisees et desengagees selon les besoins du plan et du projet; 

♦ la notification aux parties prenantes concernees des eventuels points a traiter a propos de certaines ressources; 

♦ I’influence sur les facteurs pouvant creer un changement de I’utilisation des ressources; 

♦ la gestion des changements effectifs au fur et a mesure qu’ils se realisent. 

Tout changement de la reference de base de I’echeancier ou des couts ne peut etre approuve que par le processus 
MaTtriser les changements (voir la section 4.6). 


9.6.1 MAITRISER LES RESSOURCES : DONNEES D’ENTREE 

9.6.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le plan 
de gestion des ressources. Decrit a la section 9.1.3.1, le plan de gestion des ressources fournit des instructions sur la 
fagon dont les ressources materielles doivent etre utilisees, maTtrisees et, finalement, desengagees. 

9.6.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Registre des points a traiter. II est decrit a la section 4.3.3.3. Ce registre permet d’identifier les points a traiter, 
comme le manque de ressources, les retards dans la livraison de matieres premieres ou les matieres premieres 
de mauvaise qualite. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d'experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer la martrise des ressources materielles. 

♦ Affectations des ressources materielles. Elies sont decrites a la section 9.3.3.1. Les affectations des ressources 
materielles decrivent I’utilisation prevue des ressources. Elies comprennent egalement des details, comme le 
type, la quantite, le lieu et precise si les ressources sont internes a I’organisation ou externalisee. 


354 


Premiere partie - Guide 



♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L’echeancier du projet indique les ressources qui sont 
necessaires mais aussi le moment et I’endroit ou elles le sont. 

♦ Organigramme des ressources. II est decrit a la section 9.2.3.3. L'organigramme des ressources est utile si une 
ressource doit etre remplacee ou obtenue de nouveau au cours du projet. 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Les besoins en ressources identifient le materiel, 
I’equipement, les fournitures et les autres ressources necessaires. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques identifie les risques individuels 
susceptibles d’avoir une influence sur I’equipement, le materiel ou les fournitures. 

9.6.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Elles sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent les donnees sur 
I’avancement du projet, comme le nombre et le type de ressources qui ont ete utilisees. 

9.6.1.4 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les accords conclus dans le cadre du projet constituent la base de toutes les 
ressources externes a I’organisation. Ms doivent definir les procedures lorsque de nouvelles ressources non prevues sont 
necessaires ou lorsque des points a traiter surviennent avec les ressources actuelles. 

9.6.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser les ressources, on peut citer: 

♦ les politiques en matiere de martrise des ressources et d’affectation ; 

♦ les procedures d’alerte de la hierarchie afin de gerer les points a traiter au sein de I’organisation realisatrice ; 

♦ I'archive des retours d’experience de projets anterieurs similaires. 
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9.6.2 MAITRISER LES RESSOURCES : OUTILS ET TECHNIQUES 


9.6.2.1 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. Elle est decrite a la section 9.2.2.5. Les alternatives peuvent etre analysees en vue de 
choisir la meilleure fagon de corriger les ecarts d’utilisation des ressources. Les alternatives, comme le paiement 
des heures supplementaires ou d’autres ressources de I’equipe, peuvent etre comparees au cout d’un retard ou 
de I’echelonnement des livraisons. 

♦ Analyse cout-benefice. Elle est decrite a la section 8.1.2.3. Cette analyse permet de determiner la meilleure 
action corrective des ecarts du projet en matiere de couts. 

♦ Revues de performance. Les revues de performance permettent de mesurer, de comparer et d’analyser 
I’utilisation prevue des ressources par rapport a leur utilisation reelle. L’information sur la performance d’execution 
liee au cout et a I’echeancier peut egalement etre analysee afin d’aider a identifier les points a traiter pouvant 
avoir une influence sur I’utilisation des ressources. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5. 2 . 2 . A mesure que le projet avance, I’equipe projet 
peut analyser les tendances, fondee sur des informations relatives aux performances actuelles, pour determiner 
les ressources necessaires aux prochaines etapes du projet. L'analyse de la tendance consiste a examiner les 
performances du projet dans le temps. Elle permet de determiner si ces performances s’ameliorent ou si elles 
se degradent. 

9.6.2.2 RESOLUTION DE PROBLEMES 

Elle est decrite a la section 8.2.2.7. La resolution de problemes comprend un ensemble d’outils a la disposition du 
chef de projet pour MaTtriser les ressources. Le probleme peut etre interne a I'organisation. (Par exemple, des machines 
ou infrastructures utilisees par un autre service de I’organisation n’ont pas ete liberees a temps ou du materiel a 
ete endommage en raison de mauvaises conditions de stockage.) II peut egalement etre externe a I'organisation. (Le 
principal fournisseur a fait faillite ou de mauvaises conditions meteo ont endommage les ressources.) Le chef de projet 
doit proceder etape par etape afin de resoudre le probleme. Ces etapes sont les suivantes : 

♦ I Identification du probleme. Preciser le probleme. 

♦ Definition du probleme. Diviser le probleme en problemes plus petits et plus faciles a gerer. 

♦ Enquete. Recueillir les donnees. 

♦ Analyse. Trouver la cause originelle (root cause) du probleme. 

♦ Resolution. Choisir la bonne solution parmi un eventail propose. 

♦ Verification de la solution. Determiner si le probleme a ete resolu. 
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9.6.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 


Les competences interpersonnelles et d’equipe, parfois appelees«soft skills», sont des competences personnels. 
Parmi les competences interpersonnelles et d’equipe utilisees pour ce processus, on peut citer les suivantes : 

♦ Negotiation, Elle est decrite a la section 12.2.2.5. Le chef de projet peut etre amene a negocier les ressources 
materielles supplementaires, les changements au niveau des ressources materielles ou les couts associes aux 
ressources. 

♦ Influence. Elle est decrite a la section 9.5.2.1. Grace a I’influence, le chef de projet peut resoudre des problemes 
et obtenir rapidement les ressources necessaires. 

9.6.2.4 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PMIS) 

II est decrit a la section 4.3.2.2. Le systeme d'information de management du projet peut inclure le logiciel de 
planification ou de gestion des ressources permettant de suivre I’utilisation des ressources afin de garantir que les 
bonnes ressources sont affectees aux bonnes activites au bon moment et au bon endroit. 


9.6.3 MAITRISER LES RESSOURCES : DONNEES DE SORTIE 

9.6.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L'information sur la performance d’execution inclut les informations sur 
I’avancement des travaux du projet en comparant les besoins et I’allocation des ressources a leur utilisation pour les 
activites du projet. Cette comparaison permet de montrer les lacunes en matiere de disponibilite des ressources qu’il 
conviendra de combler. 

9.6.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Le chef de projet doit deposer une demande pour tout changement apporte 
durant le processus Martriser les ressources ou lorsque des actions preventives ou correctives recommandees ont une 
incidence sur I’un des composants du plan de management du projet ou les documents du projet. Les demandes de 
changement sont passees en revue et traitees par le processus MaTtriser les changements (voir la section 4.6). 
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9.6.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources est mis 
a jour avec I’experience pratique en matiere de gestion des ressources du projet. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. L'echeancier du projet peut necessiter 
des changements de la gestion des ressources du projet. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts du projet peut 
necessiter des changements de la gestion des ressources du projet. 

9.6.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ Registre des hypotheses. II est decrit a la section 4.1.3.2. Le registre des hypotheses peut etre mis a jour avec 
de nouvelles hypotheses sur I’equipement, le materiel, les fournitures et les autres ressources materielles. 

♦ Registre des points a traiter. II est decrit a la section 4.3.3.3. Les nouveaux points a traiter souleves suite a ce 
processus sont consignes dans le registre correspondant. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour avec les techniques qui se sont revelees efficaces pour gerer la logistique des ressources, les 
dechets, les ecarts d’utilisation et les actions correctives permettant de repondre aux ecarts de ressources. 

♦ Affectations des ressources materielles. Elies sont decrites a la section 9.3.3.1. Les affectations des ressources 
materielles sont dynamiques. Elies sont susceptibles de changer en fonction de la disponibilite, du projet, de 
I'organisation, de I'environnementou d’autres facteurs. 

♦ Organigramme des ressources. II est decrit a la section 9.2.3.3. L'organigramme des ressources peut necessiter 
des changements afin de refleter I’utilisation des ressources du projet. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour avec des nouveaux 
risques associes a la disponibilite des ressources, a leur utilisation ou aux autres risques lies aux ressources materielles. 
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GESTION DES COMMUNICATIONS DU PROJET 

La gestion des communications du projet inclut les processus requis pour assurer la satisfaction des besoins en 
information du projet et de ses parties prenantes grace au developpement de supports et a la conduite d’activites visant 
a assurer un echange d’informations efficace. La gestion des communications du projet se compose de deux parties. 
La premiere consiste a elaborer une strategie afin de garantir une communication efficace pour les parties prenantes. 
La seconde consiste a mener les activites necessaires a I’execution d’une strategie de communication. 

Les processus de gestion des communications du projet sont les suivants: 

10.1 Pianifier la gestion des communications —est le processus qui consiste a elaborer une approche et un plan 
appropries pour les activites de communication du projet, conformement aux besoins en information de chaque partie 
prenante ou groupe, aux actifs organisationnels disponibles et aux besoins du projet. 

10.2 Gerer les communications —est le processus qui consiste a assurer, de maniere appropriee et en temps utile, 
la collecte, la creation, la distribution, le stockage, la recherche, la gestion, le suivi et la mise a disposition finale des 
informations du projet. 

10.3 Maitriser les communications —est le processus qui consiste a satisfaire les besoins en information du projet 
et de ses parties prenantes. 

La figure 10-1 donne une vue d’ensemble des processus de gestion des communications du projet. Les processus 
de gestion des communications du projet sont presentes comme des processus distincts aux interfaces clairement 
definies tandis que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas 
etre completement detaillees dans le Guide PMBOK®. 
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Figure 10-1. Vue d’ensemble des communications du projet 


PRINCIPAUX CONCEPTS DE LA GESTION DES COMMUNICATIONS DU PROJET 

La communication est un echange, intentionnel ou non, d’informations qui peuvent se presenter sous forme d’idees, 
d’instructions ou demotions. Les informations peuvent etre echangees des fagons suivantes :: 

♦ Ecrite. Physique ou electronique. 

♦ Orale. Face a face ou virtuelle. 

♦ Formelle ou informelle (documents officiels ou reseaux sociaux). 

♦ Non verbale. Ton de la voix et expressions faciales. 

♦ A I’aide de medias, comme des images, des actions ou simplement le choix des mots. 

♦ Le choix des mots. Souvent, il existe plusieurs mots pour exprimer une idee. Or, ces mots ou ces phrases 
peuvent avoir un sens legerement different. 
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Les communications decrivent les moyens d’envoi ou de reception des informations par le biais d’activites de 
communication, comme les reunions et les presentations, ou de supports, comme les courriels, les reseaux sociaux, les 
rapports ou les documents du projet. 

Les chefs de projet passent la majeure partie de leur temps a communiquer avec les membres de I’equipe et 
d’autres parties prenantes du projet, internes (a tous les niveaux organisationnels) et externes a I’organisation. Une 
communication efficace cree un pont entre les differentes parties prenantes susceptibles de provenir de divers contextes 
culturels et organisationnels, ayant differents niveaux d’expertise, des perspectives et des interets varies. 

Les activites de communication comprennent diverses dimensions, notamment les suivantes : 

♦ Internes. Concentration sur les parties prenantes du projet et de I'organisation. 

♦ Externes. Concentration sur les parties prenantes exterieures, comme les clients, les fournisseurs, les autres 
projets, les organisations, le gouvernement, I’auditoire et les defenseurs de I’environnement. 

♦ Formelles. Les rapports, les reunions formelles (ordinaires et extraordinaires), les ordres du jour et les comptes 
rendus des reunions, les briefings des parties prenantes et les presentations. 

♦ Informelles. Les activites de communication d’ordre general par le biais des courriels, des reseaux sociaux, des 
sites Internet et des discussions ponctuelles et informelles. 

♦ Interet hierarchique. La position de la partie prenante ou du groupe par rapport a l’equipe projet influence le 
format et le contenu du message, comme decrit ci-apres : 

■ Ascendante. Les parties prenantes de la direction generate. 

■ Descendante. L'equipe et les autres personnes qui contribueront au travail du projet. 

■ Horizontate. Les pairs du chef de projet ou de l’equipe projet. 

♦ Officielles. Les rapports annuels, les rapports aux organismes de regimentation ou gouvernementaux. 

♦ Officieuses. Les communications axees sur I’etablissement et le maintien du profil et de la reconnaissance du 
projet ainsi que sur la creation de solides relations entre l'equipe projet et ses parties prenantes grace a des 
moyens varies et souvent informels. 

♦ Ecrites et orales. Verbales (mots et inflexions vocales) et non verbales (gestuelle et actions), les reseaux sociaux, 
les sites Internet et les communiques de presse. 
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La communication traite des relations necessaires a I’obtention de bons resultats aussi bien pour le projet que pour 
le programme. Les activites et les supports de communication sonttres varies, allant des courriels et des conversations 
informelles aux reunions formelles et aux rapports reguliers du projet. L’envoi et la reception des informations se 
font consciemment ou non par le biais de mots, d’expressions faciales, de gestes ou d’autres actions. Pour gerer 
efficacement les relations avec les parties prenantes, la communication comprend I'elaboration de strategies et de 
plans prevoyant des supports et des activites de communication adaptes a la communaute des parties prenantes et 
I'application des competences afin d’ameliorer les communications prevues et ponctuelles. 

Pour qu’une communication soit reussie, deux conditions doivent etre reunies. La premiere consiste a elaborer 
une strategie de communication appropriee fondee sur les besoins du projet et des parties prenantes. A partir de 
cette strategie, un plan de gestion de la communication est developpe afin de s’assurer que les messages adequats 
sont communiques aux parties prenantes selon les divers formats et supports definis. Ces messages constituent les 
communications du projet, I’autre facteur d’une communication reussie. Les communications du projet sont les produits 
du processus de planification, traites par le plan de gestion de la communication qui definit la collecte, la creation, la 
diffusion, la conservation, la recuperation, la gestion, le suivi et I’archivage de ces supports de communication. Enfin, 
la strategie de communication et le plan de gestion de la communication constitueront la base pour suivre I'impact de 
la communication. 

Les communications du projet s'accompagnent d’efforts de prevention des problemes de comprehension et de 
communication ainsi que d’une selection rigoureuse des methodes, des messagers et des messages elabores a partir 
du processus de planification. 

Les malentendus peuvent etre limites, mais pas elimines, grace aux 5C de la communication ecrite lors de la creation 
d’un message ecrit (hors reseaux sociaux) ou oral traditionnel. 
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♦ Correct (grammaire et orthographe). Les erreurs de grammaire ou d’orthographe peuvent perturber mais 
aussi creer des distorsions dans le message au detriment de la credibilite. 

♦ Concis (expression et elimination des mots superflus). Un message concis et soigne reduit les possibility 
de malentendus quant a son intention. 

4 Clair (objectif et expression orientee vers les besoins du lecteur). II convient de s’assurer que les 
besoins et les interets de I’auditoire sont pris en compte dans le message. 

♦ Coherent (suite logique d’idees). Les idees s’articulent en une suite logique et coherente. En outre, des 
« marqueurs»sont utilises, comme I’introduction et les resumes d’idees lors de la redaction. 

♦ Controle (flot de paroles et d’idees). Le controle du debit de paroles et d’idees peut impliquer des graphiques 
ou simplement des resumes. 

Les 5C de la communication ecrite sont soutenus par les competences en communication, notamment les suivantes: 

♦ Ecoute active. Le maintien du contact avec I'orateur et le recapitulate des conversations visant a garantir un 
echange efficace d’informations. 

♦ Sensibilite aux differences culturelles et personnelles. La sensibilisation de I’equipe aux differences 
culturelles et personnelles afin d'eviter les malentendus et de renforcer la capacite de communication. 

4 Identification, definition et gestion des attentes des parties prenantes. La negociation avec les parties 
prenantes permet de limiter I’existence d’attentes contradictoires au sein de la communaute des parties prenantes. 

4 Amelioration des competences. L’amelioration des competences de tous les membres de I’equipe au cours 
des activites suivantes: 

■ la persuasion d’une personne, d’une equipe ou d’une organisation pour mener a bien une action ; 

■ la motivation des personnes, en vue d’encourager ou de rassurer; 

■ I'accompagnement, afin d’ameliorer les performances et d’obtenir les resultats escomptes ; 

■ la negociation, pour parvenir a des accords mutuellement acceptables entre les parties et la reduction des 
delais en matiere d’approbation ou de decision ; 

■ la resolution des conflits, pour prevenir des impacts perturbateurs. 

Les attributs fondamentaux des activites de communication et du developpement de supports de communication 
efficaces sont les suivants : 

■ clarte du but des communications (la definition du but); 

■ comprehension, autant que possible, des besoins et des preferences du destinataire en communication ; 

■ suivi et mesure de I’efficacite des communications. 
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TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES COMMUNICATIONS DU PROJET 


Outre I'accent place sur les parties prenantes et la reconnaissance de la valeur de leur engagement pour les projets 
et les organisations, il est essentiel d’elaborer et d'appliquer des strategies de communication appropriees afin de 
maintenir des relations efficaces. Les tendances et pratiques emergentes en gestion des communications du projet 
comprennent notamment les elements suivants : 

♦ Participation des parties prenantes aux revues de projet. Pour chaque projet, la communaute des parties 
prenantes comprend des personnes, des groupes et des organisations qui sont identifies par I'equipe projet 
comme essentiels a la realisation des objectifs du projet et a I’obtention des resultats de I’organisation. Une 
strategie de communication efficace necessite des revues regulieres et opportunes des mises a jour et du 
registre des parties prenantes afin de gerer les changements de ses membres et de leurs comportements. 

♦ Participation des parties prenantes aux reunions de projet. Les reunions de projet doivent inclure les parties 
prenantes exterieures au projet voire a I'organisation. Les pratiques inherentes aux approches agiles peuvent 
etre appliquees a tous types de projet. Elies incluent souvent les Scrums (melees quotidiennes) durant lesquelles 
les realisations et les points a traiter de la veille ainsi que les plans du travail quotidien sont discutes avec 
I’equipe projet et les principals parties prenantes. 

♦ Utilisation accrue des medias sociaux. Les medias sociaux en tant qu’infrastructure, services de reseaux sociaux 
et dispositifs personnels ont change la fagon dont les organisations et leur personnel communiquent et exercent 
leurs activites. Ms integrent differentes approches de collaboration qui s’appuient sur I’infrastructure informatique 
publique. Le networking social renvoie a la fagon dont les utilisateurs creent des reseaux de relations afin d’explorer 
leurs interets et activites avec autrui. Les outils des reseaux sociaux permettent non seulement d’echanger des 
informations mais aussi de creer des relations de confiance et d'engagement communautaire approfondies. 

♦ Approches multidimensionnelles de la communication. La strategie de communication standard pour les 
communications des parties prenantes au projet inclut toutes les technologies et respecte les preferences 
culturelles, pratiques et personnelles en matiere de langue, de medias, de contenu et d’execution. Les medias 
sociaux et les autres technologies informatiques avancees peuvent etre pris en compte, le cas echeant. Les 
approches multidimensionnelles telles que celles-ci sont plus efficaces pour communiquer avec les parties 
prenantes de differentes generations et cultures. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 


Chaque projet etant unique, I’equipe projet devra adapter Implication de chacun des processus de gestion des 
communications du projet. Parmi les considerations relatives a I’adaptation, on peut citer les elements suivants: 

♦ Parties prenantes. Les parties prenantes sont-elles internes, externes a I’organisation ou les deux ? 

♦ Emplacement geographique. Ou se trouvent les membres de I’equipe ? Sont-ils regroupes en un meme lieu ? 
Se situent-ils dans la meme region geographique ? Sont-ils repartis sur plusieurs fuseaux horaires ? 

♦ Technologie de communication. Quelles sont les technologies disponibles pour elaborer, enregistrer, transmettre, 
recuperer, suivre et conserver les supports de communication ? Quelles sont les technologies les mieux adaptees 
et les plus rentables pour communiquer avec les parties prenantes ? 

♦ Langue. La langue est I’un des principaux facteurs a prendre en compte lors des activites de communication. 
Utilise-t-on une seule ou plusieurs langues ? La complexity due a I’appartenance de membres de I’equipe a 
differents groupes de langues a-t-elle ete prise en compte ? 

♦ Gestion des connaissances. L’organisation dispose-t-elle d’une archive officielle en matiere de gestion des 
connaissances ? Cette archive est-elle utilisee ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les environnements de projet soumis a differents elements d’ambiguite et de changement ont besoin de communiquer 
plus frequemment et plus rapidement. II s’agit de simplifier et d’optimiser I'accessibilite a I'information par les membres 
de I'equipe projet par des revues frequentes et de privilegier la colocalisation autant que possible. 

En outre, la communication avec la direction et les parties prenantes est favorisee par la publication, en toute 
transparence, des elements du projet et par les revues regulieres avec les parties prenantes. 
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10.1 PLANIFIER LA GESTION DES COMMUNICATIONS 


Planifier la gestion des communications est le processus qui consiste a elaborer une approche et un plan appropries 
pour les activites de communication du projet, conformementaux besoins en information de chaque partie prenante ou 
groupe, aux actifs organisationnels disponibles et aux besoins du projet. L'interet principal de ce processus reside dans 
une approche documentee qui permet d’engager les parties prenantes de maniere efficace et effective, en presentant 
des informations pertinentes en temps opportun. Ce processus est execute periodiquement pendant toute la duree du 
projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 10-2. La figure 10-3 presente le diagramme de flux de donnees du processus. 




.1 Elaborer la charte du projet 
.2 Elaborer le plan 


.1 Jugement a dire d'expert 
.2 Analyse des exigences 


1 Plan de gestion 
de la communication 


de management du projet 

• Plan de gestion 
des ressources 

• Plan d'engagement 


en communication 
.3 Technologie 


de communication 
.4 Modeles de communication 
.5 Methodes de communication 
.6 Competences 


.2 Mises a jour du plan 
de management du projet 
• Plan d’engagement 
des parties prenantes 


des parties prenantes 
.3 Documents du projet 


.3 Mises a jour des documents 
du projet 

• Echeancier du projet 

• Registre des parties 
prenantes 


• Documentation 
des exigences 

• Registre des parties 


• Evaluation des styles 
de communication 

• Conscience politique 


interpersonnelles et d'equipe 


prenantes 

.4 Facteurs environnementaux 


• Conscience culturelle 
.7 Representation des donnees 


V 


de I'organisation 
.5 Actifs organisationnels 


• Matrice devaluation 
de I'engagement des parties 


J 


prenantes 
.8 Reunions 


Figure 10-2. Planifier la gestion des communications: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 10-3. Planifier la gestion des communications: diagramme de flux de donnees 


Un plan de gestion de la communication efficace qui reconnaTt les differents besoins en information des parties 
prenantes est elabore au debut du cycle de vie du projet. II doit etre revise regulierement et modifie si necessaire, 
lorsque la communaute des parties prenantes change ou au debut de chaque nouvelle phase du projet. 

Dans la plupart des projets, la planification des communications est effectuee tres tot, par exemple durant 
I’identification des parties prenantes et I’elaboration du plan de management du projet. 

Bien que tous les projets partagent le besoin de communiquer leurs informations, les besoins en information et les 
methodes de diffusion varient largement d’un projet a I’autre. En outre, les methodes de conservation, de recherche et 
d’archivage final des informations du projet doivent etre prises en compte et documentees tout au long de ce processus. 
Les resultats du processus Planifier la gestion des communications doivent etre revus regulierement tout au long du 
projet et, au besoin, mis a jour pour en garantir I’applicabilite. 
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10.1.1 PLANIFIER LA GESTION DES COMMUNICATIONS : DONNEES D’ENTREE 


10.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet contient la liste des principales parties prenantes mais aussi 
des informations sur leurs roles et leurs responsabilites. 

10.1.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. II donne des conseils sur la fagon dont les 
ressources de I'equipe sont classees, affectees, gerees et liberties. Les membres de I'equipe et les groupes peuvent 
avoir des exigences en communication qui doivent etre identifies dans le plan de gestion de la communication. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des parties 
prenantes identifie les strategies de gestion necessaires pour engager efficacement les parties prenantes. Ces 
strategies sont souvent appliquees grace aux communications. 

10.1.1.3 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut 
inclure les communications des parties prenantes au projet. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes permet de 
planifier les activites de communication avec les parties prenantes. 

10.1.1.4 FACTEURS ENVIRONNEMENTAUX DE L’ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion des communications, on peut citer: 

♦ la culture de I’organisation, le climat politique et le cadre de gouvernance ; 

♦ les politiques d’administration du personnel; 

♦ les seuils de tolerance aux risques des parties prenantes ; 

♦ les canaux, les outils et les systemes de communication etablis; 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 
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10.1.1.5 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion des 
communications, on peut citer: 

♦ les politiques et les procedures de I'organisation relatives aux reseaux sociaux, a la deontologie et a la securite; 

♦ les politiques et les procedures de I’organisation relatives aux points a traiter, aux risques, au changement et a 
la gestion des donnees ; 

♦ les exigences de I'organisation en matiere de communication ; 

♦ les directives sur I'elaboration, I'echange, la conservation et la recuperation des informations; 

♦ les donnees historiques et I'archive des retours d’experience ; 

♦ les donnees des parties prenantes et des communications ainsi que les informations de projets anterieurs. 

10.1.2 PLANIFIER LA GESTION DES COMMUNICATIONS : OUTILS ET TECHNIQUES 

10.1.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant 
une connaissance specialist ou une formation dans les domaines suivants : 

♦ politiques et structures du pouvoir de I'organisation ; 

♦ environnement et culture de I’organisation et d'autres organisations clientes; 

♦ approche et pratiques en matiere de gestion des changements de I'organisation ; 

♦ secteur ou type de livrables du projet; 

♦ technologies de communication de I’organisation ; 

♦ politiques et procedures organisationnelles relatives aux exigences juridiques des communications de 
I’organisation; 

♦ politiques et procedures organisationnelles relatives a la securite; 

♦ parties prenantes, y compris les clients ou les sponsors. 

10.1.2.2 ANALYSE DES EXIGENCES EN COMMUNICATION 

L'analyse des exigences en communication determine les besoins en information des parties prenantes du projet. 
Ces exigences sont definies en combinant le type et le format des informations requises avec une analyse de la 
valeur de ces informations. 
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Les sources d'information habituellement utilisees pour identifier et definir les exigences du projet en matiere de 
communication comprennent, entre autres: 

♦ les exigences des parties prenantes en information et en communication, a partir du registre des parties prenantes 
et du plan d’engagement des parties prenantes ; 

♦ le nombre de voies ou de canaux potentiels de communication, notamment les communications entre deux 
individus, entre un individu et un groupe et entre deux groupes ; 

♦ les organigrammes; 

♦ I’organisation du projet, les responsabilites, les relations et les interdependences des parties prenantes ; 

♦ I’approche du developpement; 

♦ les disciplines, les services et les domaines specialises concernes par le projet; 

♦ la logistique liee au nombre et a I’emplacement des personnes impliquees dans le projet; 

♦ les besoins en information interne (par exemple, la communication au sein des organisations); 

♦ les besoins en information externe (par exemple, la communication avec les medias, I’auditoire ou les fournisseurs); 

♦ les exigences juridiques. 

10.1.2.3 TECHNOLOGIE DE COMMUNICATION 

Les methodes utilisees pour transferer des informations entre les parties prenantes du projet peuvent varier de 
maniere significative. Parmi les methodes les plus utilisees pour la collaboration et I’echange d'informations figurent 
les conversations, les reunions, les documents ecrits, les bases de donnees, les reseaux sociaux et les sites Internet. 

Plusieurs facteurs peuvent avoir une influence sur le choix de la technologie de communication, notamment les suivants: 

♦ Urgence du besoin en information. Le niveau d’urgence, la frequence et le format des informations a 
communiquer peuvent varier en fonction du projet et de ses phases. 

♦ Disponibilite et fiabilite de la technologie. La technologie requise pour diffuser les communications du projet 
doit etre compatible, disponible et accessible a toutes les parties prenantes tout au long du projet. 

♦ Facilite d’utilisation. Le choix des technologies de communication doit etre adapte aux participants du projet. 
En outre, des formations adequates doivent etre planifiees, le cas echeant. 
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♦ Environnement du projet. II convient de determiner si I’equipe se reunit et travaille en face a face ou dans un 
environnement virtuel, si ses membres se trouvent dans le meme fuseau horaire ou dans des fuseaux differents, 
s’ils parlent differentes langues et enfin s’il existe plusieurs facteurs environnementaux du projet, comme des 
aspects culturels, susceptibles d'avoir une influence sur les communications. 

♦ Sensibilite et confidentiality des informations. Certains aspects sont a prendre en compte, notamment 

■ si les informations a communiquer sont sensiblesou confidentielles. Auquel cas, d’autres mesures de securite 
devront etre mises en place. 

■ Les politiques relatives aux reseaux sociaux a I’attention des employes afin de garantir un comportement et 
une securite appropries ainsi que la protection des informations exclusives. 

10.1.2.4 MODELES DE COMMUNICATION 

Les modeles de communication peuvent representer le processus de communication sous sa forme lineaire la plus 
basique (emetteur et recepteur), de fagon plus interactive en integrant le retour d’information (emetteur, recepteur et 
retour d'information) ou selon un modele plus complexe en ajoutant les elements humains montrant la complexity d’une 
communication entre individus. 

♦ Modele de communication emetteur/recepteur basique. Ce modele, qui decrit la communication comme 
un processus, comprend deux parties appelees I’emetteur et le recepteur. II veille a ce que le message soit 
communique avant d’etre compris. Dans un modele de communication basique, les etapes sont les suivantes : 

■ Encodage. Le message est code sous forme de symboles, comme du texte, un son ou toute autre forme 
de moyen de transmission (envoi). 

■ Transmission du message. Le message est envoye via un canal de communication. La transmission de ce 
message peut etre compromise par divers facteurs physiques, comme le manque de familiarite avec la 
technologie ou une infrastructure inappropriee. Le bruit, ainsi que d’autres facteurs, peuvent etre presents et 
contribuer a la perte d'informations lors de la transmission et/ou de la reception du message. 

■ Decodage. Le recepteur retraduit les donnees regues sous une forme qui lui est utile. 
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♦ • Modele de communication interactive. Ce modele decrit egalement la communication comme un processus 
compose de deux parties, a savoir I'emetteur et le recepteur. Toutefois, il reconnart le besoin de garantir que 
le message a ete compris. Pour ce modele, le bruit inclut les interferences ou les obstacles susceptibles de 
compromettre la comprehension du message, comme la distraction du recepteur, les variances de perceptions 
des recepteurs ou I'absence de connaissance ou d'interet approprie. Le modele de communication interactive 
comprend d’autres etapes: 

■ Accuse de reception. Une fois le message regu, le recepteur peut signaler avoir regu le message. Toutefois, 
cela ne signifie pas qu’il est d’accord avec le message, ni qu’il le comprend mais seulement qu’il I'a regu. 

■ Retour d’information/reponse. Lorsque le message regu a ete decode et compris, le recepteur encode 
des pensees et des idees dans un message et le transmet a I’emetteur original. Si I'emetteur considere 
que le retour d’information correspond au message d’origine, la communication est reussie. Lors d’une 
communication entre des personnes, le retour d'information s’obtient grace a une ecoute active, decrite 
a la section 10.2.2.6. 

Dans le cadre du processus de communication, la responsabilite de I'emetteur est de transmettre le message 
en s’assurant que I’information communiquee est claire et complete, et en confirmant que le message a ete 
correctement interprets. La responsabilite du recepteur est de s’assurer que I’information a ete regue dans son 
integralite, correctement interprets et confirmee, ou qu’une reponse appropriee a ete envoyee. Ces composants 
interviennent dans un environnement ou la communication peut etre entravee par du bruit et d’autres obstacles. 
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La communication interculturelle entraine des difficulty pour assurer une bonne comprehension du message. Les 
styles de communication peuvent varier selon les methodes de travail, I’age, la nationalite, la discipline professionnelle ou 
d’autres aspects culturels. Les personnes de cultures variees utilisent differents langages (par exemple, les documents 
de conception technique, les differents styles) et ont des attentes differentes quant aux processus et protocoles. 

Le modele de communication illustre a la figure 10-4 reprend I’idee que le message et son mode de transmission 
sont influences par I’etat emotionnel, les connaissances, les antecedents, la personnalite, la culture et les prejuges de 
I'emetteur. De meme, I'etat emotionnel, les connaissances, les antecedents, la personnalite, la culture et les prejuges de 
I'emetteur influenceront la reception et [’interpretation du message et contribuent a augmenter les obstacles ou le bruit. 

Ce modele de communication et ses ameliorations peuvent aider a elaborer des strategies et des plans pour les 
communications de personne a personne voire meme de petit groupe a petit groupe. II n’est pas adapte aux autres 
moyens de communication, comme les courriels, les messages diffuses ou les medias sociaux. 


Etat 
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■ generationnelle 

■ nationale 

• professionnelle 

• sexo-specifique 

Prejuges sur 
la personnalite 
(hypotheses) 
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Figure 10-4. Modele de communication interculturelle 
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10.1.2.5 METHODES DE COMMUNICATION 

Plusieurs methodes de communication sont utilisees pour faire circuler I’information entre les parties prenantes du 
projet. Ces methodes sont classees de la fagon generique suivante : 

♦ Communication interactive. Elle a lieu entre deux ou plusieurs parties engagees dans un echange d'information 
multidirectionnel en temps reel. Elle comprend notamment les reunions, les appels telephoniques, la messagerie 
instantanee, certaines formes de reseaux sociaux et les visioconferences. 

♦ Communication « push ». Elle est envoyee ou diffusee directement a des recepteurs specifiques qui ont besoin 
de I’information. Ceci assure la diffusion de I’information, mais ne garantit pas qu’elle ait effectivement atteint 
I'auditoire vise ou qu’elle ait ete comprise par celui-ci. Les communications«push»comprennent les lettres, les 
memos, les rapports, les courriels, les fac-similes, les messages vocaux, les blogs et les communiques de presse. 

♦ Communication « puli ». Cette communication est utilisee pour des volumes d'informations importants et 
complexes ou pour de nombreux destinataires. Elle necessite que les recepteurs puissent acceder au contenu 
en respectant les procedures de securite. Ces methodes comprennent les portails Internet, les sites intranet, 
I’apprentissage en ligne, les bases de donnees des retours d’experience ou les archives de connaissances. 

Differentes approches doivent etre appliquees afin de repondre aux besoins des principales formes de communication 
definies dans le plan de gestion de la communication : 

♦ Communication interpersonnelle. Les informations sont echangees entre des personnes, generalement en 
face a face. 

♦ Communication en petit groupe. II s’agit de la communication au sein de groupes composes d'environ trois a 
six personnes. 

♦ Communication publique. Un seul orateur s'adresse a un groupe de personnes. 

♦ Communication de masse. II existe un lien minimal entre la personne ou le groupe qui envoie le message et les 
groupes importants, parfois anonymes, a qui sont adressees les informations. 

♦ Communication a I’aide des reseaux et des medias sociaux. Elle soutient les tendances emergentes en 
matiere de communication entre deux groupes au moyen des medias et de latechnologie des medias sociaux. 
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Les methodes et les supports de communication possibles du projet comprennent, entre autres : 

♦ les panneaux d’affichage ; 

♦ les lettres d’information, les magazines internes et les magazines numeriques; 

♦ les lettres adressees au personnel/aux benevoles ; 

♦ les communiques de presse ; 

♦ les rapports annuels ; 

♦ les courriels et les intranets ; 

♦ les portails Internet et les autres archives d'informations (pour la communication«pull»); 

♦ les conversations telephoniques; 

♦ les presentations; 

♦ les briefings d’equipe et les reunions de groupes ; 

♦ les groupes de discussion ; 

♦ les reunions presentielles formelles ou informelles entre differentes parties prenantes ; 

♦ les groupes de consultation ou les forums du personnel; 

♦ les medias et les technologies des medias sociaux. 

10.1.2.6 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Evaluation des styles de communication. Cette technique permet d’evaluer les styles de communication 
et d'identifier le mode de communication a privilegier, sa forme et son contenu dans le cadre d’activites de 
communication planifiees. Cette evaluation, qui est souvent utilisee avec les parties prenantes non engagees, 
peut etre realisee a la suite d’une evaluation de I’engagement des parties prenantes (decrite a la section 13.2.2.5) 
afin d’identifier les ecarts d’engagement des parties prenantes necessitant d’autres moyens et activites de 
communication adaptes. 
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♦ Conscience politique. La conscience politique permet au chef de projet de planifier les communications 
en fonction de I'environnement du projet et de I'environnement politique de I'organisation. Elle porte sur la 
reconnaissance des rapports de force, tant formels qu’informels, mais aussi sur la volonte d’agir au sein de ces 
structures. La conscience politique consiste a comprendre les strategies de I’organisation, a savoir qui exerce 
le pouvoir et a de I’influence dans ce domaine mais aussi a developper une capacite a communiquer avec ces 
parties prenantes. 

♦ Conscience culturelle. La conscience culturelle consiste a comprendre les differences entre les personnes, les 
groupes et les organisations mais aussi a adapter la strategie de communication du projet face a ces differences. 
Cette conscience et les mesures prises minimisent les problemes de comprehension et de communication 
pouvant naTtre de differences culturelles au sein de la communaute des parties prenantes du projet. La conscience 
culturelle aide le chef de projet a planifier les communications en se fondant sur les differences culturelles et les 
exigences des parties prenantes et des membres de I'equipe. 

10.1.2.7 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figure notamment la 
matrice devaluation de I'engagement des parties prenantes. Elle est decrite a la section 13.2.2.5. La matrice devaluation 
de Lengagement des parties prenantes, illustree a la figure 13-6, identifie les ecarts entre les niveaux d'engagement 
actuel et souhaite des parties prenantes. Dans le cadre de ce processus, elle peut etre analysee plus en profondeur afin 
d’identifier les autres exigences en communication, en plus des rapports habituels, et de combler lesdits ecarts. 

10.1.2.8 REUNIONS 

Les reunions de projet incluent les reunions virtuelles ou presentielles. Elies peuvent s'appuyer sur des technologies 
de collaboration documentaire, comme les courriels et les sites Internet du projet. Le processus Planifier la gestion des 
communications exige une discussion avec I’equipe projet afin de determiner la methode la mieux appropriee pour 
mettre a jour et communiquer les informations du projet, mais aussi de repondre aux demandes d’information des 
diverses parties prenantes. 
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10.1.3 PLANIFIER LA GESTION DES COMMUNICATIONS : DONNEES DE SORTIE 


10.1.3.1 PLAN DE GESTION DE LA COMMUNICATION 

Le plan de gestion de la communication est un composant du plan de management du projet qui decrit comment les 
communications du projet sont planifiees, structures, appliquees et suivies pour etre efficaces. Ce plan contient les 
informations suivantes: 

♦ les exigences des parties prenantes en matiere de communication ; 

♦ les informations a communiquer, y compris la langue, le format, le contenu et le niveau de detail; 

♦ les processus d'escalade ; 

♦ la raison pour la diffusion de ces informations ; 

♦ I’intervalle et la frequence de diffusion des informations requises mais aussi I’accuse de reception ou la reponse, 
le cas echeant; 

♦ la personne responsable de la communication de I’information ; 

♦ la personne chargee d’autoriser la divulgation d’informations confidentielles ; 

♦ la personne ou les groupes qui recevront les informations, y compris les informations sur leurs besoins, leurs 
exigences et leurs attentes ; 

♦ les methodes ou les technologies utilisees pour transmettre les informations, telles que les memos, les courriels, 
les communiques de presse ou les reseaux sociaux; 

♦ les ressources affectees aux activites de communication, y compris le temps et le budget; 

♦ la methode pour la mise a jour et I’affinement du plan de gestion de la communication au fur et a mesure que 
le projet progresse et se developpe, comme lorsque la communaute des parties prenantes change au fil des 
differentes phases; 

♦ le glossaire pour laterminologie commune ; 

♦ les diagrammes de flux de I’information circulant au sein du projet, les flux de travail, avec I'eventuelle suite 
d’autorisations, la liste des rapports, les plans de reunions, etc.; 

♦ les contraintes issues de lois ou de regimentations specifiques, de la technology, de la politique interne de 
I'organisation, etc. 

Le plan de gestion de la communication peut inclure des directives et des modeles pour les reunions de revue du 
projet, les reunions de I’equipe de projet, les reunions virtuelles et les courriels. Le recours a un site Internet pour le 
projet et a un logiciel de gestion de projet peut etre inclus, s’ils sont utilises dans le cadre du projet. 
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10.1.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet figure notamment le plan d’engagement des parties 
prenantes decrit a la section 13.2.3.1. Ce plan peut etre mis a jour afin de refleter les processus, les procedures, 
les outils ou les techniques ayant une incidence sur I’engagement des parties prenantes concernant les decisions et 
I’execution du projet. 

10.1.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet peut etre mis a jour afin de refleter 
les activites de communication. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes peut etre 
mis a jour afin de refleter les communications planifiees. 
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10.2 GERER LES COMMUNICATIONS 


Gerer les communications est le processus qui consiste a assurer, de maniere appropriee et en temps utile, la 
collecte, la creation, la distribution, le stockage, la recherche, la gestion, le suivi et I’archivage final des informations du 
projet. L’interet principal de ce processus est qu’il offre un flux d’information efficace entre I'equipe projet et les parties 
prenantes. Ce processus est execute tout au long du projet. 

Le processus Gerer les communications identifie tous les aspects d’une communication efficace, notamment le choix des 
technologies, des methodes et des techniques appropriees. De plus, il doit garantir une souplesse au niveau des activites 
de communication, de maniere a adapter les methodes et les techniques aux besoins changeants des parties prenantes 
et du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 10-5. La figure 10-6 presente le diagramme de flux de donnees du processus Gerer les communications. 


Gerer les communications 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion 
des ressources 

• Plan de gestion 

de la communication 

• Plan d'engagement 
des parties prenantes 

.2 Documents du projet 

• Journal des changements 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Rapport de qualite 

• Rapport sur les risques 

• Registre des parties 
prenantes 

.3 Rapports sur la performance 
d'execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 
- 1 _/ 


Outils et techniques 


.1 Technologie 
de communication 
.2 Methodes de communication 
.3 Competences 
en communication 

• Competence en matiere 
de communication 

• Retour d'information 

• Communication non verbale 

• Presentations 

.4 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.5 Etablissement des rapports 
du projet 
.6 Competences 

interpersonnelles et d'equipe 

• Ecoute active 

• Gestion des conflits 

• Conscience culturelle 

• Gestion des reunions 

• Networking 

• Conscience politique 
.7 Reunions 

V_/ 


Donnees de sortie 


.1 Communications du projet 
.2 Mises a jour du plan 
de management du projet 

• Plan de gestion 

de la communication 

• Plan d'engagement 
des parties prenantes 

.3 Mises a jour des documents 
du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Registre des risques 

• Registre des parties 
prenantes 

.4 Mises a jour des actifs 
organisationnels 

v _y 


Figure 10-5. Gerer les communications: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 



Plan de management du projet 

• Plan de gestion des ressources 

• Plan de gestion de la communication 

• Plan d’engagement des parties 
prenantes 


Documents 
du projet 



Documents du projet 

• Journal des changements 

• Journal des points a traiter 

• Registre des retours d’experience 

• Rapport de qualite 

• Rapport sur les risques 

• Registre des parties prenantes 



4.5 




MaTtriser le travail 




du projet 




• Rapports sur la performance 
d’execution 


Entreprise/ 

Organisation 


• Facteurs environnementaux 
de (’organisation 

• Actifs organisationnels 


• Communications du projet 


Mises a jour des documents du projet 

• Journal des points a traiter 

• Registre des retours d’experience 

• Echeancier du projet 

• Registre des risques 

• Registre des parties prenantes 


Documents 
du projet 



10.2 



Plan 


Gerer les 


.► 

de management 


communications 


Mises a jour du plan 

du projet 




de management du projet 



Plan de gestion 
de la communication 
Plan d’engagement 
des parties prenantes 


• Mises a jour des actifs 
organisationnels 


Entreprise/ 

Organisation 


Figure 10-6. Gerer les communications: diagramme de flux de donnees 
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Ce processus ne consiste pas seulement a diffuser les informations pertinentes : il cherche a garantir que les 
informations communiquees aux parties prenantes du projet ont ete etablies et formatees de maniere appropriee 
mais aussi regues par I’auditoire cible. II permet egalement aux parties prenantes de demander des informations 
supplementaires, des clarifications et des discussions. Afin de garantir une gestion des communications efficace, il 
convient d’utiliser plusieurs techniques et de prendre en compte divers points, notamment les suivants: 

♦ Modeles emetteur/recepteur. II s’agit d’integrer des boucles de reaction (en anglais,«feedback loop ») afin 
de donner I'occasion aux parties prenantes d'interagir, de participer et d'eliminer les obstacles entravant une 
communication efficace. 

♦ Choix des medias. II s’agit des decisions concernant I'application des supports de communication pour repondre 
aux besoins specifiques du projet, comme les situations dans lesquelles la communication ecrite est preferable 
a la communication orale, la redaction d’un memo informel a celle d’un rapport formel, I’utilisation des options 
push/pull et le choix de latechnologie appropriee. 

♦ Style d’ecriture. Ceci concerne I’utilisation appropriee de la voix active par opposition a la voix passive, la 
structure des phrases et le choix des mots. 

♦ Gestion des reunions. Elle est decrite a la section 10.2.2.6. II s'agit de preparer un ordre du jour, d'inviter les 
participants indispensables et de s’assurer de leur presence. II fauttraiter les conflits survenant lors d’une reunion 
ou resultant d’un proces-verbal et de mesures de suivi inadequats ou de la presence des mauvaises personnes. 

♦ Presentations. II faut etre conscient de I'impact du langage non verbal et de la conception des supports visuels. 

♦ Facilitation. Elle est decrite a la section 4.1.2.3. II faut savoir comment encourager le consensus et franchir 
les obstacles, comme les dynamiques de groupe difficiles, et maintenir I’interet et I’enthousiasme au sein des 
membres du groupe. 

♦ Ecoute active. Elle est decrite a la section 10.2.2.6. L'ecoute active suppose de confirmer la reception du 
message, de clarifier les points problematiques, de comprendre le message et d’eliminer les obstacles empechant 
une bonne comprehension. 


10.2.1 GERER LES COMMUNICATIONS : DONNEES D’ENTREE 

10.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants : 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources decrit les 
communications necessaires a la gestion des ressources materielles ou de I’equipe. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
decrit comment les communications du projet seront planifiees, structures, suivies et maitrisees. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement 
des parties prenantes decrit comment les parties prenantes seront engagees grace a des strategies de 
communication appropriees. 
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10.2.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des changements. II est decrit a la section 4.6.3.3. Le registre des changements permet de 
communiquer les changements ainsi que les demandes de changement approuvees, reportees ou rejetees aux 
parties prenantes concernees. 

♦ Journal des points a traiter. II est decrit a la section 4.6.3.3. Les informations sur les points a traiter sont 
communiquees aux parties prenantes concernees. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du 
projet, relatifs a la gestion des communications, peuvent etre appliques aux phases ulterieures afin d’ameliorer 
I'efficacite des communications et du processus de communication. 

♦ Rapport de qualite. II est decrit a la section 8.2.3.1. Les informations contenues dans le rapport de qualite 
concernent les problemes de qualite ainsi que les ameliorations des processus, des projets et des produits. 
Ces informations sont transmises aux personnes aptes a entreprendre des actions correctives dans le but de 
repondre aux attentes de qualite du projet. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques presente des informations 
sur les sources du risque global du projet et recapitule les risques individuels du projet identifies. Ces informations 
sont communiquees aux charges de risque et aux autres parties prenantes concernees. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes identifie les 
personnes, les groupes ou les organisations qui auront besoin de differents types d’information. 

10.2.1.3 RAPPORTS SUR LA PERFORMANCE D’EXECUTION 

Ms sont decrits a la section 4.5.3.1. Ces rapports sont transmis aux parties prenantes du projet grace a ce processus, 
comme defini dans le plan de gestion de la communication. Les rapports sur la performance d’execution incluent, par 
exemple, les rapports d’etat et les rapports d’avancement. Les rapports sur la performance d’execution peuvent contenir 
des graphiques et des informations sur la valeur acquise, les previsions et les lignes de tendance, des diagrammes 
de consommation des reserves («reserve burndown charts »), des histogrammes des defauts, des informations sur 
I'execution du contrat et des syntheses des risques. Ms peuvent etre presentes sous la forme de tableaux de bord, de 
diagrammes a code couleur ou d’autres representations utiles pour creer une sensibilisation et generer des decisions 
et des actions. 
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10.2.1.4 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur ce processus, on peut citer: 

♦ la culture de I’organisation, le climat politique et le cadre de gouvernance ; 

♦ les politiques d’administration du personnel; 

♦ les seuils de risques des parties prenantes ; 

♦ les canaux, les outils et les systemes de communication etablis; 

♦ les tendances, les pratiques ou les habitudes mondiales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 

10.2.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur ce processus, on peut citer: 

♦ les politiques et les procedures de I’organisation relatives aux reseaux sociaux, a I’ethique et a la securite; 

♦ les politiques et les procedures de I’organisation relatives aux points a traiter, aux risques, au changement et a 
la gestion des donnees ; 

♦ les exigences de I’organisation en matiere de communication ; 

♦ les directives standardises sur elaboration, I’echange, la conservation et la recuperation des informations; 

♦ les donnees historiques de projets anterieurs, y compris I’archive des retours d’experience. 

10.2.2 GERER LES COMMUNICATIONS : OUTILS ET TECHNIQUES 

10.2.2.1 TECHNOLOGIE DE COMMUNICATION 

Elle est decrite a la section 10.1.2.3. Parmi les facteurs qui influencent la technologie figurent la colocalisation ou non 
de I'equipe, la confidentiality des informations a communiquer, les ressources disponibles aux membres de I’equipe et 
[influence de la culture de I’organisation sur la tenue des reunions et des discussions. 

10.2.2.2 METHODES DE COMMUNICATION 

Elies sont decrites a la section 10.1.2.5. Le choix des methodes de communication doit permettre une marge de 
manoeuvre en cas de changement aussi bien de la communaute des parties prenantes que de leurs besoins et attentes. 
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10.2.2.3 COMPETENCES EN COMMUNICATION 


Parmi les techniques de communication pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Competence en matiere de communication. Une combinaison de competences en communication adaptees 
qui tient compte des facteurs comme la clarte des buts des messages principaux, les relations efficaces, le 
partage d’informations et les actions de leadership. 

♦ Retour d’intormation. II donne des informations sur les reactions a regard des communications, d’un livrable ou 
d’une situation. II permet de faciliter la communication interactive entre le chef de projet et I’equipe mais aussi 
entre toutes les autres parties prenantes du projet. II s'agit par exemple du coaching, du tutorat et de la negotiation. 

♦ Communication non verbaie. La communication non verbale inclut le langage corporel approprie pour 
transmettre la signification grace a des gestes, au ton de la voix et aux expressions faciales. Limitation et le 
contact visuel sont egalement des techniques importantes. Les membres de I’equipe doivent etre conscients de 
la fagon dont ils s’expriment, a travers ce qu’ils disent ou ne disent pas. 

♦ Presentations. Une presentation designe la transmission formelle d’informations et/ou de documents. Parmi les 
presentations claires et efficaces des informations liees au projet destinees aux parties prenantes concernees, 
figurent notamment: 

■ les rapports d'avancement et les mises a jour des informations aux parties prenantes ; 

■ les informations contextuelles pour appuyer la prise de decisions; 

■ les informations generates sur le projet et ses objectifs dans le but de mettre en avant la visibility de I’equipe 
ainsi que le travail du projet; 

■ les informations specifiques visant a renforcer la comprehension et le soutien au travail et aux objectifs du projet. 
Les presentations seront reussies si le contenu et I’execution tiennent compte de ce qui suit: 

■ I'auditoire, ses attentes et ses besoins; 

■ les besoins et les objectifs du projet et de I’equipe projet. 
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10.2.2.4 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PROJECT MANAGEMENT INFORMATION 
SYSTEM, PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d'information de gestion du projet permettent aux parties prenantes 
d’obtenir facilement les informations dont ils ont besoin en temps opportun. Les informations du projet sont gerees et 
diffusees par le biais d’une variete d’outils, notamment les suivants : 

♦ Outils electroniques de management de projet. Logiciel de management de projet, logiciel de reunion et de 
bureau virtuel, interfaces web, portails et tableaux de bord de projet specialises et outils de gestion collaborative 
du travail. 

♦ Gestion des communications electroniques. Courriel, telecopie, messagerie vocale, visioconference, audio 
conference et par Internet, sites Internet et publication par Internet. 

♦ Gestion des reseaux sociaux. Sites Internet et publication par Internet, blogs et applications permettant de 
prendre contact avec les parties prenantes et de former des communautes en ligne. 

10.2.2.5 ETABLISSEMENT DES RAPPORTS DU PROJET 

L'etablissement des rapports du projet est I'acte qui consiste a recueillir et a diffuser les informations du projet. 
Ces informations sont distributes a de nombreux groupes de parties prenantes. Elies doivent etre adaptees afin de 
fournir des renseignements a un niveau de detail et sous un format appropries pour chaque type de partie prenante. 
Le format peut aller d’une simple communication a des presentations et des rapports personnalises plus elabores. Les 
informations peuvent etre preparees de fagon reguliere ou ponctuelle. Si les rapports sur la performance d’execution 
represented les donnees de sortie du processus Martriser le travail du projet, ce processus elabore des rapports, des 
presentations de projet, des blogs ainsi que d’autres types de communication ponctuelle lies au projet. 
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10.2.2.6 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Ecoute active. Les techniques d’ecoute active supposent de confirmer la reception du message, de clarifier les 
points problematiques, de comprendre le message et d’eliminer les obstacles empechant une bonne comprehension. 

♦ Gestion des conflits. Elle est decrite a la section 9.5.2.1. 

♦ Conscience cultureile. Elle est decrite a la section 10.1.2.6. 

♦ Gestion des reunions. Elle permet de prendre des mesures afin de garantir que les reunions atteignent les 
objectifs prevus de maniere efficace et effficiente. La gestion des reunions suit les etapes suivantes : 

■ preparer et distribuer I’ordre du jour enongant les objectifs de la reunion ; 

■ veiller a ce que les reunions debutent et se terminent aux heures annoncees; 

■ s'assurer que les bons participants sont invites et presents ; 

■ s'entenirausujet; 

■ gerer les attentes, les points a traiter et les conflits lors de la reunion. 

■ consigner toutes les actions et les personnes qui ont ete chargees de mener a bien I’action ; 

♦ Networking. II s’agit d’echanger des informations avec d’autres personnes et de nouer des contacts. Grace 
aux reseaux, les chefs de projet et leurs equipes ont acces aux organisations informelles afin de resoudre les 
problemes, d’influencer les actions de leurs parties prenantes et d’accroTtre le soutien des parties prenantes vis- 
a-vis du travail et des resultats du projet, ameliorant ainsi les performances. 

♦ Conscience politique. Elle est decrite a la section 10.1.2.6. La conscience politique aide le chef de projet a 
solliciter convenablement I’engagement des parties prenantes afin de conserver leur soutien tout au long du projet. 

10.2.2.7 REUNIONS 

Les reunions soutiennent les actions definies dans la strategie et le plan de communication. 
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10.2.3 GERER LES COMMUNICATIONS : DONNEES DE SORTIE 


10.2.3.1 COMMUNICATIONS DU PROJET 

Parmi les supports de communication du projet figurent notamment les rapports de performance, I'etat des livrables, 
I'avancement par rapport a I’echeancier, les couts encourus, les presentations ainsi que toute autre information requise 
par les parties prenantes. 

10.2.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I'organisation par I’intermediaire d’une demande de changement. Les elements du plan de management du projet qui 
sont susceptibles d’etre mis a jour suite a I’execution de ce processus sont notamment les suivants : 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Si les changements sont apportesaux 
principes de communication du projet a la suite de ce processus, ils apparaissent dans le plan de communication 
du projet. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Les exigences en communication 
des parties prenantes et les strategies de communication convenues peuvent etre mises a jour a la suite de 
ce processus. 

10.2.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter est mis a jour afin 
de refleter les problemes de communication du projet ou le nombre de communications utilisees pour traiter les 
problemes survenus. 

♦ Registre des retours d’experience. II est decrit a la section 4.3.3.1. Le registre des retours d’experience est mis 
a jour a I’aide des informations sur les difficulty rencontrees et les moyens pour les eviter et sur les principes 
qui ont permis ou non de gerer les communications. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L’echeancier du projet peut etre mis a jour afin de refleter 
I'etat des activites de communication. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour afin de saisir les 
risques associes a la gestion des communications. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes peut etre 
mis a jour afin d'inclure les informations sur les activites de communication avec les parties prenantes du projet. 
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10.2.3.4 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels susceptibles d'etre mis a jour a la suite de ce processus, figurent entre autres : 

♦ les enregistrements du projet, tels que la correspondance, les memos, les comptes rendus des reunions et les 
autres documents utilises pour le projet; 

♦ les presentations et les rapports planifies et ad hoc du projet. 


10.3 MAITRISER LES COMMUNICATIONS 

MaTtriser les communications est le processus qui consiste a satisfaire les besoins en information du projet et de ses 
parties prenantes. L’interet principal de ce processus reside dans le flux optimal d’information, tel que defini dans le plan 
de gestion de la communication et le plan d’engagement des parties prenantes. Ce processus est execute tout au long 
du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 10-7. La figure 10-8 presente le diagramme de flux de donnees du processus. 


Maitriser les communications 


Donnees d’entree V Outils et techniques V Donnees de sortie 


1 Elaborer le plan 
de management du projet 

• Plan de gestion 
des ressources 

• Plan de gestion 
de la communication 

• Plan d'engagement 
des parties prenantes 

.2 Documents du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Communications du projet 
.3 Donnees de performance 

d'execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

V___ 


.1 Jugement a dire d'expert 
.2 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

.3 Analyse des donnees 

• Matrice devaluation 

de I'engagement des parties 
prenantes 
.4 Competences 

interpersonnelles et d'equipe 

• Observation et discussion 
.5 Reunions 

V_ 


1 Information sur 
la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 

• Plan de gestion 

de la communication 

• Plan d'engagement 
des parties prenantes 

.4 Mises a jour des documents 
du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Registre des parties 
prenantes 

V_/ 


Figure 10-7. Maitriser les communications : donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 10-8. Maitriser les communications: diagramme de flux de donnees 


Le processus Maitriser les communications determine si les supports et les activites de communication planifies ont 
eu I’effet souhaite d’accroTtre ou de conserver le soutien des parties prenantes vis-a-vis des livrables et des resultats 
attendus du projet. L’impact et les consequences des communications du projet doivent etre soigneusement evalues et 
suivis afin de s’assurer que le message approprie avec son contenu (la meme signification pour I’emetteur et le recepteur) 
est diffuse a I’auditoire adequat, via le bon canal, au bon moment. Le processus Maitriser les communications peut 
necessiter differentes methodes, comme les enquetes de satisfaction des clients, le recueil des retours d’experience, la 
surveillance de I’equipe, la revision des donnees du journal des points a traiter ou revaluation des changements de la 
matrice devaluation de I’engagement des parties prenantes decrites a la section 13.2.2.5. 

Le processus Maitriser les communications peut declencher une iteration des processus Planifier la gestion 
des communications et/ou Gerer les communications afin d’ameliorer leur efficacite a I’aide d’activites et de plans 
supplementaires, voire modifies. Ces iterations illustrent la nature continue des processus de gestion des communications 
du projet. Tout point a traiter, indicateur cle de performance (KPI), risque ou conflit peut engendrer une revision immediate. 
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10.3.1 MATTRISER LES COMMUNICATIONS : DONNEES D’ENTREE 


10.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources peut etre 
utilise pour comprendre I’organisation actuelle du projet ainsi que tout changement grace a la connaissance des 
roles et des responsabilites mais aussi des organigrammes du projet. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
contient le plan pour collecter, creer et diffuser les informations de maniere opportune. II identifie les membres de 
I’equipe, les parties prenantes et le travail necessaire au processus de communication. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des parties 
prenantes identifie les strategies de communication planifiee pour engager les parties prenantes. 

10.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter retrace I’historique 
du projet en consignant les problemes d’engagement des parties prenantes ainsi que leur resolution. 

♦ Registre des retours d’experience. II est decrit a la section 4.4. 3.1. Les retours d'experience du debut du projet 
peuvent etre appliques aux phases ulterieures afin d’ameliorer I’efficacite des communications. 

♦ Communications du projet. Elies sont decrites a la section 10.2.3.1. Elies fournissent des informations sur les 
communications qui ont ete diffusees. 

10.3.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent des informations sur le 
type et le nombre de communications qui ont deja ete diffusees. 
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10.3.1.4 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus MaTtriser les 
communications, on peut citer: 

♦ la culture de I'organisation, le climat politique et le cadre de gouvernance ; 

♦ les canaux, les outils et les systemes de communication etablis; 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 

10.3.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser les communications, on 
peut citer: 

♦ les politiques et les procedures de I’organisation relatives aux reseaux sociaux, a la deontologie et a la securite; 

♦ les exigences de I’organisation en matiere de communication ; 

♦ les directives standardises sur I'elaboration, I’echange, la conservation et la recuperation des informations; 

♦ les donnees historiques et I’archive des retours d’experience de projets anterieurs; 

♦ les donnees des parties prenantes et des communications ainsi que les informations de projets anterieurs. 

10.3.2 MAITRISER LES COMMUNICATIONS : OUTILS ET TECHNIQUES 
10.3.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ les communications avec I’auditoire, la communaute et les medias et les communications dans un environnement 
international, entre des groupes virtuels ; 

♦ les communications et les systemes de management de projet. 
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10.3.2.2 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PROJECT MANAGEMENT INFORMATION 
SYSTEM, PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d'information de gestion du projet fournissent au chef de projet des 
outils standardises afin de collecter, de conserver et de communiquer aux parties prenantes internes et externes les 
informations dont elles ont besoin selon le plan de communication. Les informations contenues dans le systeme sont 
suivies afin d’evaluer leurs validite et efficacite. 

10.3.2.3 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees figure notamment la matrice devaluation 
de I'engagement des parties prenantes (section 13.2.2.5) qui fournit des informations sur I’efficacite des activites 
de communication. Pour ce faire, il convient de passer en revue les changements entre les niveaux d’engagement 
souhaites et actuels et d’adapter les communications, le cas echeant. 

10.3.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
l’observation/la conversation, comme decrit a la section 5.2.2.6. La discussion et le dialogue avec I'equipe projet aident 
a determiner la methode la mieux appropriee pour mettre a jour et communiquer la performance du projet et egalement 
a repondre aux demandes d'information des parties prenantes. L'observation et la conversation permettent au chef 
de projet d’identifier les points a traiter au sein de I’equipe, les conflits entre les personnes ou les problemes de 
performance individuelle. 

10.3.2.5 REUNIONS 

Les reunions presentielles ou virtuelles sont utilisees pour prendre des decisions, repondre aux demandes des parties 
prenantes et avoir des discussions avec les fournisseurs et les autres acteurs du projet. 


10.3.3 MAITRISER LES COMMUNICATIONS : DONNEES DE SORTIE 

10.3.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d’execution inclut des donnees sur la 
performance de la communication du projet en comparant les communications mises en place avec celles qui etaient 
planifiees. Elle tient egalement compte des retours d’information, comme les resultats des sondages sur I'efficacite de 
la communication. 
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10.3.3.2 DEMANDES DE CHANGEMENT 


Elies sont decrites a la section 4.3.3.4. Le processus MaTtriser les communications requiert souvent des ajustements, 
des actions et des interventions sur les activites de communication definies dans le plan de gestion de la communication. 
Les demandes de changement sont traitees par le processus MaTtriser les changements (voir la section 4.6). 

Ces demandes de changement peuvent conduire a: 

♦ la revision des exigences en communication des parties prenantes, y compris la diffusion des informations, leur 
contenu ou leur format et le mode de diffusion des parties prenantes; 

♦ les nouvelles procedures pour eliminer les goulets d’etranglement. 

10.3.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
est mis a jour avec de nouvelles informations afin de rendre les communications plus efficaces. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des parties 
prenantes est mis a jour afin de refleter la situation reelle des parties prenantes, leurs besoins en communication 
et leur importance. 

10.3.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter peut etre mis a jour 
avec de nouvelles informations sur les points a traiter souleves, leur avancement et leur resolution. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d'experience peut 
etre mis a jour avec les causes des points a traiter, le raisonnement a I'origine des actions correctives choisies 
et les autres retours d’experience en communication, le cas echeant. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes peut etre 
mis a jour a I’aide des exigences revisees en communication des parties prenantes. 
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GESTION DES RISQUES DU PROJET 

La gestion des risques du projet inclut les processus de planification de la gestion des risques, d'identification, 
d’analyse, de planification des reponses, ainsi que d’execution des reponses aux risques et de maTtrise des risques dans 
le cadre d’un projet. Les objectifs de la gestion des risques du projet visent a accroTtre la probabilite et/ou I'impact des 
risques positifs mais aussi a reduire la probabilite et/ou I’impact des risques negatifs, afin d’optimiser les chances de 
reussite du projet. 

Les processus de gestion des risques du projet sont les suivants : 

11.1 Planifier la gestion des risques —Ce processus consiste a definir comment conduire les activites de gestion 
des risques d’un projet. 

11.2 Identifier les risques —est le processus qui consiste a identifier les risques individuels et les sources du risque 
global du projet, ainsi qu’a en documenter les caracteristiques. 

11.3 Effectuer I’analyse qualitative des risques —est le processus qui consiste a hierarchiser les risques 
individuels du projet pour analyse et actions ulterieures en evaluant leur probabilite d’occurrence et leur impact et 
autres caracteristiques. 

11.4 Effectuer I’analyse quantitative des risques —Ce processus consiste a chiffrer I’effet combine des risques 
individuels identifies du projet et des autres sources d’incertitude sur I’ensemble des objectifs du projet. 

11.5 Planifier les reponses aux risques —Ce processus consiste a developper des options, selectionner des 
strategies et convenir d’actions visant a gerer I’exposition au risque global du projet mais aussi a traiter chaque risque 
individuel du projet. 

11.6 Executer les reponses aux risques —Ce processus consiste a executer les plans de reponse aux risques convenus. 

11.7 Maltriser les risques —Ce processus consiste a suivre la mise en oeuvre des plans de reponse aux risques, a 
faire le suivi des risques identifies, a identifier de nouveaux risques, a les analyser et a evaluer I’efficacite du processus 
de gestion des risques tout au long du projet. 

La figure 11-1 donne une vue d’ensemble des processus de gestion des risques du projet. Les processus de gestion 
des risques du projet sont presentes comme des processus distincts aux interfaces clairement definies tandis que, dans 
la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre completement detaillees 
dans le Guide PMBOK®. 
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Vue d’ensemble de la gestion 
des risques du projet 


11.1 Planifier la gestion 
des risques 


.1 Donnees d'entree 

.1 Elaborer la charte du projet 
.2 Elaborer le plan 
de management du projet 
.3 Documents du projet 
.4 Facteurs 
environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettecbniques 

.1 Jugement a dire d'expert 
.2 Analyse des donnees 
.3 Reunions 

.3 Donnees de sortie 

.1 Plan de gestion des risques 
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11.5 Planifier 
les reponses aux risques 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettecbniques 
.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Competences 
interpersonnelles et 
d'equipe 

.4 Strategies pour 
les menaces 
.5 Strategies pour les 
opportunity 
.6 Strategies de reponse 
conditionnelles 
.7 Strategies pour le risque 
global du projet 
.8 Analyse des donnees 
.9 Prise de decision 

.3 Donnees de sortie 
.1 Demandes de cbangement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour 
des documents du projet 

V.___/ 


11.2 Identifier 
les risques 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Accords 
.4 Documents 
d'approvisionnements 
.5 Facteurs 
environnementaux 
de I'organisation 
.6 Actifs organisationnels 

.2 Outils et techniques 

.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Competences 
interpersonnelles et 
d'equipe 
.5 Listes rapides 
.6 Reunions 

.3 Donnees de sortie 
.1 Registre des risques 
.2 Rapport sur les risques 
.3 Mises a jour 
des documents du projet 
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11.3 Effectuer l’analyse 
qualitative des risques 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils et techniques 
.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Competences 
interpersonnelles 
et d'equipe 

.5 Categorisation des risques 
.6 Representation des donnees 
.7 Reunions 

.3 Donnees de sortie 
.1 Mises a jour 
des documents du projet 
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11.7 Maitriser 
les risques 


11.4 Effectuer l’analyse 
quantitative des risques 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils et techniques 
.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Competences 
interpersonnelles 
et d'equipe 
.4 Representations 
de I'incertitude 
.5 Analyse des donnees 

.3 Donnees de sortie 
.1 Mises a jour 
des documents du projet 
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11.6 Appliquer 
les reponses aux risques 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Actifs organisationnels 

.2 Outils et techniques 
.1 Jugement a dire d'expert 
.2 Competences 
interpersonnelles 
et d'equipe 

.3 Systeme d'information 
de gestion du projet 
(Project Management 
Information System, PMISj 

.3 Donnees de sortie 
.1 Demandes de changement 
.2 Mises a jour des documents 
du projet 

V _ 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 
.4 Rapports sur 
la performance d'execution 

.2 Outils et techniques 
.1 Analyse des donnees 
.2 Audits 
.3 Reunions 

.3 Donnees de sortie 
.1 Information sur 
la performance d'execution 
.2 Demandes de cbangement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour 
des documents du projet 
.5 Mises a jour des actifs 
organisationnels 

V _/ 


Figure 11-1. Vue d’ensemble de la gestion des risques du projet 
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PRINCIPAUX CONCEPTS DE LA GESTION DES RISQUES DU PROJET 


Tous les projets sont risques, car il s’agit de demarches uniques presentant differents degres de complexite et 
destinees a produire des benefices. Ce resultat est obtenu dans un contexte de contraintes et d’hypotheses, tout en 
repondant aux attentes des parties prenantes qui peuvent etre contradictoires et evolutives. L'organisation choisit de 
prendre un risque lie a un projet de maniere controlee et intentionnelle pour creer de la valeur tout en equilibrant le 
risque et la recompense. 

La gestion des risques du projet vise a identifier et gerer les risques qui ne sont pas couverts par les autres processus 
du management de projet. Lorsqu’ils ne sont pas geres, ces risques peuvent ecarter le projet du plan et ainsi I’empecher 
d’atteindre les objectifs de projet. Par consequent, Pefficacite de la gestion des risques du projet est directement liee a 
la reussite du projet. 

Au sein de chaque projet, le risque existe a deux niveaux. Chaque projet comporte des risques individuels qui peuvent 
avoir un effet sur la realisation des objectifs du projet. II est egalement important de tenir compte du risque global du 
projet, qui decoule de la combinaison de risques individuels de projet et d’autres sources d’incertitude. Les processus 
de gestion des risques du projet concernent les deux niveaux de risque des projets, definis comme suit: 

♦ Le risque individuel du projet est un evenement ou une condition possible dont la concretisation aurait un 
impact positif ou negatif sur un ou plusieurs objectifs du projet. 

♦ Le risque global du projet est I’effet de I’incertitude sur I’ensemble du projet, provenant de toutes les sources 
d’incertitude possibles, comme les risques individuels, qui represented I’exposition des parties prenantes aux 
implications des variations, positives ou negatives, des resultats du projet. 

Les risques individuels du projet peuvent avoir un effet positif ou negatif sur les objectifs du projet, s’ils se realised. 
La gestion des risques du projet vise a exploiter ou consolider les risques positifs (opportunites) tout en evitant ou 
en attenuant les risques negatifs (menaces). Les menaces non gerees peuvent generer des points a traiter ou des 
problemes, tels qu’un retard, des depassements de couts, un ecart de performance ou une perte de reputation. Les 
opportunites saisies peuvent permettre d’obtenir des benefices, comme la reduction du temps et des couts, une 
performance amelioree ou une meilleure reputation. 

Le risque global du projet peut egalement etre positif ou negatif. La gestion du risque global du projet vise a maintenir 
I’exposition aux risques du projet dans une plage de valeurs acceptable en reduisant les facteurs de variance negatifs, 
en favorisant les facteurs de variance positifs et en renforgant la probabilite d’atteindre les objectifs globaux du projet. 
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Des risques continueront a se presenter tout au long de la duree de vie du projet. II convient done d’adopter une 
approche iterative pour mener les processus de gestion des risques du projet. Le risque est initialement considere lors 
de la planification du projet en elaborant la strategie du projet. Le risque doit egalement etre maTtrise et gere a mesure 
que le projet avance dans le but de garantir qu'il reste sur la bonne voie et que les nouveaux risques sont considers. 

Afin de gerer les risques de maniere efficace, dans le cadre d’un projet en particulier, I’equipe projet doit connaitre 
le niveau d’exposition aux risques acceptable pour poursuivre les objectifs du projet. Ce niveau est defini par des seuils 
de risque mesurables qui refletent I’appetence au risque de I'organisation et des parties prenantes du projet. Les seuils 
de risque expriment le degre de variance acceptable autour d’un objectif de projet. Ms sont explicitement indiques et 
communiques a I’equipe projet et refletes dans les definitions des niveaux d’impact de risque du projet. 

TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES RISQUES DU PROJET 

La priority en matiere de gestion des risques du projet s’etend afin de garantir que tous les types de risque sont 
pris en consideration et que les risques du projet sont compris dans un contexte plus large. Les tendances et pratiques 
emergentes en gestion des risques du projet comprennent notamment les elements suivants : 

♦ Risques fondes sur des non-evenements. La plupart des projets ciblent uniquement les risques qui constituent 
des evenements futurs incertains pouvant ou non survenir. Parmi les risques fondes sur des evenements, 
on peut citer les exemples suivants : un vendeur principal peut faire faillite au cours du projet, le client peut 
changer I’exigence apres I’achevement de la conception ou un sous-traitant peut proposer des ameliorations 
aux processus d’exploitation standard. 

II est de plus en plus reconnu que les risques fondes sur des non-evenements doivent etre identifies et geres. II 
existe deux grands types de risques fondes sur des non-evenements: 

■ Risque de variability. II existe une incertitude concernant certaines des caracteristiques principales d’un 
evenement, d’une activity ou d’une decision planifiee. Parmi les risques de variability, on peut citer les 
exemples suivants: la productivity peut etre superieure ou inferieure a I’objectif, le nombre d’erreurs trouvees 
lors des tests peut etre superieur ou inferieur a ce qui etait prevu ou les conditions meteorologiques peuvent 
etre peu Clementes lors de la phase de construction. 

■ Risque d’ambigui'te. II existe une incertitude concernant ce qui pourrait arriver dans I’avenir. Les domaines 
du projet ou des connaissances imparfaites peuvent nuire a la capacity du projet a atteindre ses objectifs 
sont les suivants : des elements de I’exigence ou de la solution technique, des evolutions futures dans les 
cadres reglementaires ou la complexity systemique inherente au projet. 
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Les risques de variability peuvent etre traites a I'aide de la methode de Monte-Carlo, avec la plage de variance 
refletee dans les distributions de probability, suivie d’actions visant a reduire la propagation des resultats 
possibles. Pour gerer les risques d’ambigui'te, les domaines presentant un deficit de connaissances ou de 
comprehension sont definis, puis I'ecart est comble grace a I’obtention de donnees d’entree specialises 
externes ou d’un benchmarking par rapport aux bonnes pratiques. L'ambigui'te est egalement traitee au moyen 
du developpement incremental, de prototypes ou d’une simulation. 

♦ Resilience du projet. L'existence d’un risque emergent devient manifeste, avec une sensibilisation accrue aux 
risques non identifiables («unknowable-unknowns»). Certains risques ne peuvent etre reconnus qu'apres s’etre 
produits. Les risques emergents peuvent etre elimines en developpant la resilience du projet. Pour ce faire, 
chaque projet doit disposer des elements suivants : 

■ un bon niveau de reserve pour alea du budget et de I’echeancier pour les risques emergents, en plus d’un 
budget specifique pour les risques identifies; 

■ des processus de projet flexibles qui peuvent resister au risque emergent tout en maintenant le cap global 
vers les objectifs du projet, y compris une solide gestion des changements; 

■ une equipe projet autonome et fiable, ayant fixe des objectifs qu'elle realisera dans les delais convenus ; 

■ la revue frequente des signes avant-coureurs afin d’identifier les risques emergents le plus tot possible ; 

■ des donnees d’entree claires fournies par les parties prenantes pour preciser les domaines ou le perimetre du 
projet ou la strategie peuvent etre ajustees en reaction aux risques emergents. 

♦ Gestion des risques integree. Les projets existent dans un contexte organisationnel. Ms peuvent faire partie 
d’un programme ou d’un portefeuille. Le risque existe a chacun de ces niveaux, et les risques doivent etre 
attribues et geres au niveau approprie. Certains risques identifies a des niveaux superieurs seront delegues a 
I’equipe projet pour la gestion. Certains risques de projet seront transmis a des niveaux superieurs s’ils sont 
mieux geres en dehors du projet. Une approche coordonnee de la gestion des risques a I’echelle de I'entreprise 
permet de garantir que les risques sont geres de maniere harmonieuse et coherente a tous les niveaux. En outre, 
la structure des programmes et des portefeuilles integre une gestion des risques efficace, offrant la plus grande 
valeur globale pour un niveau donne d’exposition aux risques. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 


Chaque projet etant unique, il est necessaire d’adapter la fagon dont les processus de gestion des risques du projet 
sont executes. Parmi les considerations relatives a I'adaptation, on peut citer les elements suivants : 

♦ Taille du projet. La taille du projet en termes de budget, de duree, de perimetre ou de taille de I’equipe 
necessite-t-elle une approche plus detaillee de la gestion des risques ? Ou est-elle suffisamment petite pour 
justifier un processus de risque simplifie ? 

♦ Complexity du projet. Les hauts niveaux en matiere d'innovation, de nouvelles technologies, d’accords 
commerciaux, d’interfaces ou de dependences externes qui augmentent la complexity du projet exigent-ils 
une approche approfondie du risque ? Ou le projet est-il suffisamment simple pour qu’un processus de risque 
reduit suffise ? 

♦ Importance du projet. Quelle est I’importance strategique du projet ? Le niveau de risque de ce projet a-t-il 
augmente parce qu'il vise a produire des opportunites d’avancee majeure, qu’il traite des elements importants 
pour la performance de I'organisation ou qu’il implique une innovation de produit majeure ? 

♦ Approche de developpement. S’agit-il d’un projet type waterfall ou les processus de risque peuvent etre suivis 
de maniere sequentielle et iterative, ou le projet suit-il une approche agile ou le risque est traite au debut de 
chaque iteration et en cours d’execution ? 

L’adaptation des processus de gestion des risques du projet pour satisfaire a ces considerations fait partie des 
processus de gestion des risques du projet. Les resultats des decisions d’adaptation sont enregistres dans le plan de 
gestion des risques. 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les environnements a haute variability presentent, par definition, une incertitude et un risque plus grands. Pour 
repondre a ce probleme, les projets geres a I'aide d’approches adaptatives s’appuient sur les revues frequentes des 
produits incrementaux du travail et les equipes projet transversales pour accelerer le partage des connaissances et 
garantir les bonnes comprehension et gestion du risque. Le risque est examine lors de la selection du contenu de 
chaque iteration. Les risques seront egalement identifies, analyses et geres au cours de chaque iteration. 

Par ailleurs, les exigences sont conservees dans un document evolutif qui est regulierement mis a jour, et les priorites 
peuvent etre reorganisees a mesure que le projet avance, sur la base d’une meilleure comprehension de I’exposition 
aux risques actuelle. 
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11.1 PLANIFIER LA GESTION DES RISQUES 


Planifier la gestion des risques est le processus qui consiste a definir comment conduire les activites de gestion 
des risques d’un projet. L’interet principal de ce processus est qu’il garantit que le niveau, le type et la visibilite de la 
gestion des risques sont correctement adaptes a la fois aux risques et a I'importance du projet pour I’organisation et les 
autres parties prenantes. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. Les 
donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 11 -2. La 
figure 11 -3 presente le diagramme de flux de donnees du processus. 




.1 Elaborer la charte du projet 


.1 Jugement a dire d’expert 
.2 Analyse des donnees 


.1 Plan de gestion des risques 


.2 Elaborer le plan 

de management du projet 
• Tous les composants 


prenantes 
.3 Reunions 


• Analyse des parties 


V 


.3 Documents du projet 
• Registre des parties 
prenantes 


.4 Facteurs environnementaux 
de I'organisation 


.5 Actifs organisationnels 


V 


Figure 11-2. Planifier la gestion des risques: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 11-3. Planifier la gestion des risques: diagramme de flux de donnees 


Le processus Planifier la gestion des risques devrait commencer des la conception du projet et devrait etre termine 
au debut du projet. II pourra etre necessaire de revoir ce processus ulterieurement au cours du cycle de vie du projet, 
par exemple lors d’un changement de phase important, en cas de changement significatif dans le perimetre du projet 
ou si une revue ulterieure de I’efficacite de la gestion des risques determine que le processus Planifier la gestion des 
risques du projet necessite d’etre modifie. 


11.1.1 PLANIFIER LA GESTION DES RISQUES : DONNEES D’ENTREE 

11.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet documente la description et les limites du projet, les exigences 
de haut niveau ainsi que les risques. 
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11.1.1.2 PLAN DE MANAGEMENT DU PROJET 


II est decrit a la section 4.2.3.1. Au cours de la planification de la gestion des risques du projet, tous les plans de 
management subsidiaires approuves doivent etre pris en consideration, afin que le plan de gestion des risques soit 
coherent avec eux. La methodologie decrite dans les autres composants du plan de management du projet peuvent 
influer sur le processus Planifier la gestion des risques. 

11.1.1.3 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pource processus figure 
notamment le registre des parties prenantes, tel que decrit a la section 13.1.3.1. Le registre des parties prenantes 
contient des details sur les parties prenantes du projet et donne une vue d’ensemble de leurs roles au sein du projet et 
de leur attitude a regard du risque dans le cadre de ce projet. II permet de determiner les roles et les responsabilites en 
matiere de gestion des risques du projet mais aussi de definir les seuils de risque pour le projet. 

11.1.1.4 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation susceptibles d’influencer le processus Planifier la gestion des 
risques figurent, entre autres, les seuils de risque global definis par I’organisation ou les principales parties prenantes. 

11.1.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier la gestion des risques, 
on peut citer: 

♦ la politique interne de I’organisation en matiere de risque ; 

♦ les categories de risques, eventuellement organisees sous la forme d’un organigramme des risques; 

♦ les definitions courantes des concepts et des termes lies au risque; 

♦ les formats d’enonce du risque; 

♦ les modeles de plan de gestion des risques, le registre des risques et le rapport sur les risques ; 

♦ les roles et responsabilites; 

♦ les niveaux d’autorite pour la prise de decision ; 

♦ I’archive des retours d’experience de projets anterieurs similaires. 
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11.1.2 PLANIFIER LA GESTION DES RISQUES : OUTILS ET TECHNIQUES 


11.1.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation aux themes suivants: 

♦ connaissance de I’approche adoptee par I'organisation pour gerer le risque, y compris la gestion des risques 
d’entreprise, le cas echeant; 

♦ adaptation de la gestion des risques aux besoins specifiques d’un projet; 

♦ types de risque susceptibles de survenir sur des projets dans le meme domaine. 

11.1.2.2 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus, on peut notamment citer une 
analyse des parties prenantes (voir la section 13.1.2.3) visant a determiner I’appetit pour le risque des parties prenantes 
du projet. 

11.1.2.3 REUNIONS 

Le plan de gestion des risques peut etre elabore dans le cadre de la reunion de lancement du projet ou d’une reunion 
de planification speciale. Les participants peuvent inclure le chef de projet, des membres selectionnes de I’equipe 
projet, les parties prenantes principals ou des membres de I’equipe ayant la responsabilite de gerer le processus de 
gestion des risques du projet. D’autres personnes exterieures a I'organisation peuvent egalement etre conviees, parmi 
lesquelles des clients, des vendeurs et des regulateurs. Un facilitateur competent peut aider les participants a rester 
concentres sur leur tache, a s’accorder sur des aspects majeurs de I'approche en matiere de risque, a identifier et a 
surmonter les sources de parti pris mais aussi a resoudre tout disaccord eventuel. 

Les plans necessaires a la realisation des activites de gestion des risques sont definis au cours de ces reunions et 
documents dans le plan de gestion des risques (voir la section 11.1.3.1). 


404 


Premiere partie - Guide 



11.1.3 PLANIFIER LA GESTION DES RISQUES : DONNEES DE SORTIE 


11.1.3.1 PLAN DE GESTION DES RISQUES 

Le plan de gestion des risques est un composant du plan de management du projet et decrit comment les activites 
de gestion des risques seront structures et conduites. Le plan de gestion des risques peut inclure la totalite ou une 
partie des elements suivants : 

♦ Strategie de risque. Elle decrit I'approche globale adoptee pour gerer le risque du projet. 

♦ Methodologie. Elle definit les approches, les outils et les sources de donnees specifiques qui seront utilises pour 
la gestion des risques du projet. 

♦ Roles et responsabilites. Ils definissent les membres de I’equipe en charge de la conduite, des activites de 
support et de la gestion des risques pour chaque type d’activite decrite dans le plan de gestion des risques. En 
outre, ils clarifient leurs responsabilites. 

♦ Financement. II identifie les fonds necessaires pour realiser les activites associees a la gestion des risques du 
projet. II etablit les protocoles d’utilisation des reserves pour aleas et imprevus. 

♦ Calendrier. II definit a quel moment et a quelle frequence les processus de gestion des risques seront effectues 
au cours du cycle de vie du projet. En outre, il etablit les activites de gestion des risques a inclure dans I’echeancier 
du projet. 

♦ Categories de risques. Elies fournissent un moyen de regrouper les risques individuels du projet. Les categories 
de risques sont generalement structures sous la forme d’un organigramme des risques (risk breakdown 
structure, RBS). II s'agit de la representation hierarchique des sources de risque potentielles (voir I'exemple 
fourni a la figure 11-4). Un organigramme des risques permet a I’equipe projet de tenir compte de toutes les 
sources d’ou peuvent decouler les risques individuels du projet. II peut etre utile lors de I'identification des 
risques ou de la categorisation des risques identifies. L’organisation peut avoir un organigramme des risques 
generique a utiliser pourtous les projets. II peut egalement exister plusieurs organigrammes des risques-cadres 
pour differents types de projets, ou encore le projet peut elaborer un organigramme des risques adapte. Si aucun 
organigramme des risques n’est utilise, une organisation peut utiliser un cadre special de categorisation des 
risques, qui peut prendre la forme d’une simple liste de categories ou d’une structure fondee sur les objectifs 
du projet. 
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ORGANIGRAMME 
DES RISQUES 
NIVEAU 0 

ORGANIGRAMME 
DES RISQUES 
NIVEAU 1 

ORGANIGRAMME 

DES RISQUES 

NIVEAU 2 



1.1 

Definition du perimetre 



1.2 

Definition des exigences 



1.3 

Estimations, hypotheses et contraintes 


1. RISQUE TECHNIQUE 

1.4 

Processus techniques 



1.5 

Technologie 



1.6 

Interfaces techniques 



Etc. 



2.1 

Management de projet 



2.2 

Management de programme/portefeuille 


2. RISQUE 

DE MANAGEMENT 

2.3 

Gestion des operations 


2.4 

Organisation 


2.5 

Ressources 

0. TOUTES 

LES SOURCES 


2.6 

Communication 


Etc. 

DE RISQUE 

DU PROJET 


3.1 

Termes et conditions contractuels 


3.2 

Approvisionnement interne 



3.3 

Fournisseurs et vendeurs 


3. RISQUE 

COMMERCIAL 

3.4 

Contrats de sous-traitance 


3.5 

Stabilite des clients 



3.6 

Partenariats et joint ventures 



Etc. 



4.1 

Legislation 



4.2 

Taux de change 



4.3 

Site/installations 


4. RISQUE EXTERNE 

4.4 

Environnement/meteo 



4.5 

Concurrence 



4.6 

Regimentation 



Etc. 


Figure 11-4. Exemple d’organigramme des risques 
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♦ Appetence au risque des parties prenantes. L'appetence au risque des parties prenantes principales est 
consignee dans le plan de gestion des risques, car il donne des details sur le processus Planifier la gestion 
des risques. En particulier, l’appetence au risque des parties prenantes devrait etre exprimee sous la forme de 
seuils de risque mesurables autour de chaque objectif du projet. Ces seuils determined le niveau acceptable 
d’exposition au risque global du projet. Ils renseignent les definitions de la probabilite et des impacts a utiliser 
lors de revaluation et du classement des risques individuels du projet par ordre de priorite. 

♦ Definitions de la probabilite et de I’impact des risques. Les definitions de la probabilite des risques et des 
niveaux d'impact sont specifiques au contexte du projet et refletent l'appetence au risque et les seuils de risque 
de I'organisation et des parties prenantes principales. Le projet peut generer des definitions specifiques pour la 
probabilite et les niveaux d’impact ou bien demarrer avec des definitions generates fournies par I'organisation. Le 
nombre de niveaux il lustre le degre de detail requis pour le processus de gestion des risques du projet: plus il est 
eleve, plus I'approche de risque est detaillee (generalement cinq niveaux); moins il est eleve, plus le processus 
est simple (habituellement trois niveaux). Le tableau 11-1 donne des exemples de definitions de probabilite et 
d’impacts par rapport a trois objectifs du projet. Ces echelles peuvent etre utilisees pour evaluer a la fois les 
menaces et les opportunites en considerant les definitions des impacts de maniere negative pour les menaces 
(retard, cout additionnel et performances insuffisantes) et de maniere positive pour les opportunites (temps ou 
cout reduit et meilleures performances). 


Tableau 11-1. Exemple de definitions de probabilite et d’impacts 


ECHELLE 

PROBABILITE 

+/~ IMPACT SUR LES OBJECTIFS DU PROJET 

TEMPS 

COUT 

QUALITE 

Tres elevee 

>70% 

>6 mois 

>5 M$ 

Impact tres important sur la fonctionnalite globale 

Elevee 

51-70% 

3-6 mois 

1 M$-5 M$ 

Impact important sur la fonctionnalite globale 

Moyenne 

31-50% 

1-3 mois 

501 K$-1 M$ 

Certain impact sur les principaux domaines fonctionnels 

Faible 

11-30% 

1-4 semaines 

100 KS-500 K$ 

Impact mineur sur la fonctionnalite globale 

Tres faible 

1-10% 

1 semaine 

<100 K$ 

Impact mineur sur les fonctions secondaires 

Nulle 

<1% 

Aucun 

changement 

Aucun 

changement 

Aucun changement de la fonctionnalite 
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♦ Matrice de probability et d’impact. Elle est decrite a la section 11.3.2.6. Les regies de repartition par priority 
peuvent etre definies par I’organisation en amont du projet et etre integrees aux actifs organisationnels. Elies 
peuvent etre aussi adaptees au projet specifique. Les opportunites et les menaces sont representees dans une 
matrice de probability et d’impact commune en utilisant les definitions positives de I’impact pour les opportunites 
et les definitions negatives de I'impact pour les menaces. Des termes descriptifs (tres eleve(e), eleve(e), moyen(ne), 
faible et tres faible) ou des valeurs numeriques peuvent etre utilisees pour la probability et I’impact. Lorsque des 
valeurs numeriques sont utilisees, elles peuvent etre multiplies afin de donner une notation probability-impact 
pour chaque risque, laquelle permet d’evaluer la priority relative des risques individuels au sein de chaque niveau 
de priority. Un exemple de matrice de probability et d’impact est presente a la figure 11 -5, qui montre egalement 
une possibility de grille de notation numerique des risques. 


'<D 


!5 

TO 

-Q 

O 

£ 



Menaces 

Opportunites 

Tres elevee 
0.90 

0.05 

0.09 

0.18 

0.36 

0.72 

0.72 

0.36 

0.18 

0.09 

0.05 

Elevee 

0.70 

0.04 

0.07 

0.14 

0.28 

0.56 

0.56 

0.28 

0.14 

0.07 

0.04 

Moyenne 

0.50 

0.03 

0.05 

0.10 

0.20 

0.40 

0.40 

0.20 

0.10 

0.05 

0.03 

Faible 

0.30 

0.02 

0.03 

0.06 

0.12 

0.24 

0.24 

0.12 

0.06 

0.03 

0.02 

Tres faible 
0.10 

0.01 

0.01 

0.02 

0.04 

0.08 

0.08 

0.04 

0.02 

0.01 

0.01 


Tres faible 
0.05 

Faible 

0.10 

Modere 

0.20 

El eve 
0.40 

Tres eleve 
0.80 

Tres eleve 
0.80 

Eleve 

0.40 

Modere 

0.20 

Faible 

0.10 

Tres faible 
0.05 



Impact negatif 



Impact posltlf 



Tres elevee 
0.90 

Elevee 

0.70 


Moyenne 

0.50 

Faible 

0.30 

Tres faible 
0.10 


•v 

o 

cr 

&) 

O’ 


O' 


Figure 11-5. Exemple de matrice de probability et d’impact avec grille de notation 


♦ Formats des rapports. Les formats des rapports definissent comment les resultats des processus de gestion 
des risques seront documentes, analyses et communiques. Cette section du plan de gestion des risques decrit le 
contenu et le format du registre des risques et du rapport sur les risques, ainsi que toute autre donnee de sortie 
devant etre generee par les processus de gestion des risques du projet. 

♦ Suivi. II documente comment les activites concernant les risques seront enregistrees mais aussi la fagon dont 
les processus de gestion des risques seront controles. 


408 


Premiere partie - Guide 





























11.2 IDENTIFIER LES RISQUES 


Identifier les risques est le processus qui inclut I’identification des risques individuels et des sources du risque 
global du projet ainsi qu’a en documenter les caracteristiques. L’interet principal de ce processus reside dans la 
documentation des risques individuels existants dans le cadre du projet et des sources du risque global du projet. II 
reunit des informations qui permettent a I’equipe projet de repondre de maniere appropriee aux risques identifies. Ce 
processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de 
ce processus sont presentes a la figure 11 -6. La figure 11 -7 presente le diagramme de flux de donnees du processus. 


Identifier les risques 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion 
des exigences 

• Plan de gestion 
de I'echeancier 

• Plan de gestion des couts 

• Plan de gestion de la qualite 

• Plan de gestion 
des ressources 

• Plan de gestion des risques 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

.2 Documents du projet 

• Journal des hypotheses 

• Estimations de couts 

• Estimations de durees 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Documentation 
des exigences 

• Besoins en ressources 

• Registre des parties 
prenantes 

.3 Accords 
.4 Documents 

d'approvisionnements 
.5 Facteurs environnementaux 

de I'organisation 
.6 Actifs organisationnels 

V___ J 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Collecte des donnees 

• Brainstorming 

• Checklists 

• Entretiens 

.3 Analyse des donnees 

• Analyse des causes 
originelles 

• Analyse des hypotheses et 
des contraintes 

• Analyse SWOT 

• Analyse des documents 
.4 Competences 

interpersonnelles et d’equipe 

• Facilitation 
.5 Listes rapides 
.6 Reunions 

V_/ 


Donnees de sortie 


.1 Registre des risques 
.2 Rapport sur les risques 
.3 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des retours 
d'experience 

V___ 


Figure 11-6. Identifier les risques: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


Plan de management du projet 

• Plan de gestion des exigences 

• Plan de gestion de I’echeancier 

• Plan de gestion des couts 

• Plan de gestion des ressources 

• Plan de gestion de la qualite 

• Plan de gestion des risques 

• Reference de base du perimetre 

• Reference de base de I’echeancier 

• Reference de base des couts 


Documents 
du projet 


Documents du projet 

• Journal des hypotheses 

• Estimations de couts 

• Estimations de durees 

• Journal des points a traiter 

• Registre des retours d’experience 

• Documentation des exigences 

• Besoins en ressources 

• Registre des parties prenantes 


12.1 
Planifier 
la gestion des 
approvisionnements 


Documents d’approvisionnement 


12.2 

Proceder aux 
approvisionnements 


Entreprise/ 

Organisation 



11.2 





Identifier 



du projet 


les risques 


• Registre des risques 





• Rapport sur les risques 



Mises a jour des documents du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des retours d'experience 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 11-7. Identifier les risques: diagramme de flux de donnees 
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Le processus Identifier les risques couvre a la fois les risques individuels du projet et les sources du risque global 
du projet. Les participants aux activites d'identification des risques comprennent, entre autres, le chef de projet, les 
membres de I'equipe projet, le specialiste en gestion des risques (s’il y en a un), les clients, les experts d’un domaine 
particulier externes a I’equipe projet, les utilisateurs, d’autres chefs de projet, les responsables des operations, les 
parties prenantes et les experts en gestion des risques au sein de I'organisation. Bien que ces personnes soientsouvent 
des participants cles pour I'identification des risques, toutes les parties prenantes au projet devraient etre encouragees 
a identifier les risques individuels du projet. II est particulierement important d’impliquer I'equipe projet de sorte qu’elle 
puisse developper et maintenir un sentiment d'appropriation et de responsabilite des risques individuels du projet, au 
niveau du risque global du projet et aux actions de reponse qui leur sont associees. 

Lors de la description et de I’enregistrement des risques individuels du projet, il convient d’utiliser un format coherent 
pour les enonces afin de garantir que chaque risque est bien compris sans equivoque mais aussi de permettre de les 
analyser et d’elaborer des reponses en toute efficacite. Des charges de risque pour les risques individuels du projet 
peuvent etre designes dans le cadre du processus Identifier les risques et seront confirmes au cours du processus 
Effectuer I'analyse qualitative des risques. Des reponses aux risques preliminaires peuvent egalement etre identifies 
et enregistrees. Elies seront examinees et confirmees dans le cadre du processus Planifier les reponses aux risques. 

Identifier les risques est un processus iteratif etant donne que de nouveaux risques individuels peuvent apparaitre au 
cours du cycle de vie du projet et que le niveau du risque global du projet changera lui aussi. La frequence d'iteration 
et la participation a chaque cycle d'identification des risques varient selon la situation et seront definies dans le plan de 
gestion des risques. 


11.2.1 IDENTIFIER LES RISQUES : DONNEES D’ENTREE 

11.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences peut indiquer 
les objectifs du projet particulierement risques. 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. Le plan de gestion de I’echeancier peut 
identifier les domaines faisant I’objet d’incertitude ou d’ambiguite. 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. Le plan de gestion des couts peut identifier les 
domaines faisant I’objet d'incertitude ou d’ambiguite. 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. Le plan de gestion de la qualite peut identifier les 
domaines faisant I'objet d'incertitude ou d’ambiguite ou les domaines dans lesquels des hypotheses majeures 
pouvant donner lieu a un risque ont ete formulees. 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources peut 
permettre d’identifier les domaines faisant I’objet d’incertitude ou d’ambiguite ou les domaines dans lesquels 
des hypotheses majeures pouvant donner lieu a un risque ont ete formulees. 
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♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques donne des 
informations sur les roles et responsabilites lies au risque, indique la fagon dont les activites de gestion des 
risques sont incluses dans le budget et I’echeancier mais aussi decrit les categories de risque, qui peuvent etre 
representees sous la forme d’un organigramme des risques (voir la figure 11 -4). 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre inclut 
les livrables et leurs criteres d’acceptation, dont certains peuvent engendrer un risque. Elle contient egalement le 
WBS qui peut servir de cadre pour structurer les techniques d'identification des risques. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. La reference de base de I’echeancier 
peut etre passee en revue pour identifier les echeances des jalons et des livrables faisant I'objet d'incertitude ou 
d’ambigui'te ou bien pour lesquelles des hypotheses majeures pouvant donner lieu a un risque ont ete formulees. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts peut etre 
passee en revue pour identifier les couts ou les besoins en financement faisant I’objet d’incertitude ou d’ambigui'te 
ou bien pour lesquels des hypotheses majeures pouvant donner lieu a un risque ont ete formulees. 

11.2.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Les hypotheses et les contraintes consignees dans le 
journal des hypotheses peuvent generer des risques individuels de projet et sont susceptibles d’avoir un impact 
sur le niveau de risque global du projet. 

♦ Estimations de couts. Elies sont decrites a lasection 7.2.3.1. Les estimations de couts fournissent des evaluations 
quantitatives des couts du projet, idealement exprimees sous la forme d’une plage de valeurs, indiquant le degre 
de risque. Dans ce cadre, une revue structuree des documents permet d’indiquer si I’estimation actuelle est 
insuffisante et presente un risque pour le projet. 

♦ Estimations de durees. Elies sont decrites a la section 6.4.3.1. Les estimations de durees fournissent des 
evaluations quantitatives des durees du projet, idealement exprimees sous la forme d’une plage de valeurs, 
indiquant le degre de risque. Dans ce cadre, une revue structuree des documents permet d’indiquer si I’estimation 
actuelle est insuffisante et presente un risque pour le projet. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les points a traiter consignes dans le journal des 
points a traiter peuvent generer des risques individuels de projet et sont susceptibles d’avoir un impact sur le 
niveau de risque global du projet. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience sur les risques 
identifies au cours des premieres phases du projet sont examines afin de determiner si des risques similaires 
pourraient se repeter dans la suite du projet. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences enumere 
les exigences du projet et permet a I'equipe d’identifier celles qui pourraient presenter des risques. 
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♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Les besoins en ressources fournissent des 
evaluations quantitatives des besoins en ressources du projet, idealement exprimees sous la forme d’une plage 
de valeurs, indiquant le degre de risque. Dans ce cadre, une revue structure des documents permet d’indiquer 
si I’estimation actuelle est insuffisante et presente un risque pour le projet. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes indique les 
individus ou les groupes susceptibles de participer a I’identification des risques du projet. II detaille egalement 
les personnes disponibles pour agir en qualite de charges de risque. 

11.2.1.3 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Si le projet necessite un approvisionnement en ressources externes, les accords 
peuvent donner des informations, telles que les dates des jalons, le type de contrat, les criteres d’acceptation et les 
recompenses et penalties, qui peuvent presenter des menaces ou des opportunity. 

11.2.1.4 DOCUMENTS D’APPROVISIONNEMENTS 

Ms sont decrits a la section 12.3.1.4. Si le projet necessite un approvisionnement en ressources externes, il convient 
de passer en revue les documents d’approvisionnements. En effet, I’approvisionnement en biens et services a I’exterieur 
de I'organisation peut augmenter ou reduire le risque global du projet mais aussi introduire des risques individuels 
supplementaires. Les documents d’approvisionnements etant mis a jour tout au long du projet, les documents les plus 
recents peuvent etre passes en revue pour verifier les risques, par exemple, les rapports de performance des vendeurs, 
les demandes de changement approuvees et les informations concernant les inspections. 

11.2.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Identifier les 
risques, on peut citer: 

♦ les documents publies, notamment les bases de donnees de risques ou les checklists vendues dans le commerce; 

♦ les recherches universitaires ; 

♦ les resultats du benchmarking ; 

♦ les etudes de projets similaires menees dans le secteur. 

11.2.1.6 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Identifier les risques, on peut citer: 

♦ les fichiers du projet, y compris les donnees reelles ; 

♦ la martrise des processus du projet et de I’organisation ; 

♦ les formats d’enonce du risque; 

♦ les checklists de projets anterieurs similaires. 
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11.2.2 IDENTIFIER LES RISQUES : OUTILS ET TECHNIQUES 


11.2.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist liee a des projets ou des secteurs d'activite similaires. Le chef de projet devrait identifier de 
tels experts et les inviter a examiner tous les aspects des risques individuels du projet ainsi que les sources du risque 
global du projet, sur la base de leur experience passee et de leurs domaines d’expertise. Le parti pris eventuel des 
experts devrait etre pris en compte dans le cadre de ce processus. 

11.2.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Brainstorming. Le but du brainstorming (voir la section 4.1.2.2) consiste a obtenir une liste exhaustive des risques 
individuels de projet et des sources du risque global du projet. L’equipe projet tient generalement des sessions 
de brainstorming, souvent avec un ensemble d’experts pluridisciplinaires externes a I’equipe. Les idees sont 
generees sous la conduite d'un facilitateur, soit dans le cadre d’une session de brainstorming ouverte, soit lors 
d’une session utilisant des techniques plus structures. Les categories de risques, comme dans I’organigramme 
des risques, peuvent etre utilisees en tant que cadre de travail. II convient de bien veiller a ce que les risques 
identifies lors d’une session de brainstorming soient clairement decrits, puisque cette technique peut generer 
des idees qui ne sont pas abouties. 

♦ Checklists. Une checklist est une liste d’elements, d'actions ou de points a examiner. Elle est souvent utilisee 
comme aide-memoire. Les checklists d’identification des risques sont elaborees sur la base des donnees 
historiques mais aussi des connaissances accumulees au cours de projets similaires et a partir d’autres sources 
d’information. Elies constituent un moyen efficace pour collecter les retours d’experience de projets similaires 
acheves : elles enumerent les risques individuels specifiques a un projet qui se sont presents precedemment 
et qui peuvent etre pertinents pour le projet en cours. L'organisation peut conserver une checklist des risques 
fondee sur ses projets acheves ou utiliser les checklists de risques generiques du secteur. Bien qu’une checklist 
puisse etre rapide et simple a utiliser, il est impossible d’en elaborer une exhaustive. Ainsi, il convient de veiller 
a ce que la checklist ne soit pas utilisee dans le but d’eviter I’effort d’une identification convenable des risques. 
L’equipe projet devrait egalement examiner des elements qui ne figurent pas sur la checklist. En outre, il convient 
de passer la checklist en revue de temps en temps afin de la mettre a jour avec les nouvelles informations et de 
supprimer ou d’archiver les donnees obsoletes. 

♦ Entretiens. Les risques individuels du projet et les sources du risque global du projet peuvent etre identifies en 
interrogeant les participants experiments au projet, les parties prenantes et des experts dans le domaine. Les 
entretiens (voir la section 5.2.2.2) doivent avoir lieu dans un environnement de confiance et de confidentiality afin 
d’encourager les contributions honnetes et impartiales. 
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11.2.2.3 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des causes originelles. L’analyse des causes originelles (voir la section 8.2.2.2) est generalement 
utilisee afin de decouvrir les causes sous-jacentes a un probleme et de developper une action preventive. Elle 
peut etre utilisee pour identifier les menaces en commengant avec I’enonce d’un probleme (par exemple, le 
projet peut etre retarde ou hors budget) et en examinant les menaces susceptibles d’etre a I’origine du probleme 
en question. La meme technique peut etre utilisee pour trouver des opportunites en commengant par I’enonce 
d’un benefice (par exemple, une livraison anticipee ou inferieure au budget) et en examinant les opportunites 
pouvant offrir le benefice en question. 

♦ Analyse des hypotheses et des contraintes. Chaque projet et son plan de management sont congus et elabores 
en fonction d’un ensemble d’hypotheses et d’une serie de contraintes. Ces hypotheses et ces contraintes sont 
souvent incluses dans la reference de base du perimetre et les estimations du projet. L’analyse des hypotheses 
et des contraintes examine la validite de ces dernieres afin de determiner lesquelles presented un risque pour 
le projet. Des menaces peuvent etre identifies en raison de I’inexactitude, de I'instabilite, de I’incoherence 
ou du caractere incomplet des hypotheses. Les contraintes peuvent generer des opportunites en eliminant ou 
assouplissant un facteur limitatif qui nuit a I’execution d’un projet ou d’un processus. 

♦ Analyse SWOT. Cette technique permet d’examiner le projet sous plusieurs aspects, a savoir les forces, les 
faiblesses, les opportunites et les menaces (strengths, weaknesses, opportunities, and threats, SWOT). Elle est 
utilisee dans le cadre de I'identification des risques pour elargir I’etendue des risques identifies, en y incluant 
les risques crees en interne. Elle commence par I'identification des forces et des faiblesses de I'organisation, 
en se concentrant soit sur le projet, soit sur ^organisation, soit plus largement sur le domaine d’activite. Grace 
a (’analyse SWOT, on identifie alors, pour le projet, toutes les opportunites et toutes les menaces provenant 
respectivement des forces et des faiblesses de ^organisation. L’analyse etudie egalement le degre selon lequel 
les forces de I'organisation peuvent contrebalancer les menaces. Elle determine si les faiblesses peuvent entraver 
les opportunites. 

♦ Analyse des documents. Elle est decrite a la section 5.2.2.3. Les risques peuvent etre identifies a la suite d’une 
revue structure des documents du projet, notamment les plans, les hypotheses, les contraintes, les fichiers des 
projets anterieurs, les contrats, les accords et la documentation technique. Toute incertitude ou ambiguite dans 
les documents du projet aussi bien que les incoherences dans un document ou entre des documents peuvent 
indiquerun risque. 
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11.2.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment la 
facilitation (voir la section 4.1.2.3). La facilitation permet d'ameliorer I’efficacite de nombreuses techniques utilisees 
pour identifier les risques individuels du projet et les sources du risque global du projet. Un facilitateur competent peut 
aider les participants a rester concentres sur la tache d’identification des risques, a suivre exactement la methode 
associee a la technique, a bien decrire les risques, a identifier et a surmonter les sources de parti pris mais aussi a 
resoudre tout disaccord eventuel, 

11.2.2.5 LISTES RAPIDES 

Une liste rapide est une liste predetermines de categories de risques pouvant generer des risques individuels et 
constituer des sources de risque global du projet. La liste rapide peut etre utilisee comme cadre pour aider I’equipe projet a 
trouver des idees en cas d’utilisation des techniques d’identification des risques. Les categories de risques appartenant au 
niveau le plus bas de I’organigramme des risques peuvent constituer une liste rapide pour identifier les risques individuels 
du projet. Certains cadres strategies courants sont plus adaptes pour identifier les sources de risque global du projet, 
par exemple I’analyse PESTEL (Politique, Economique, Sociologique, Technologique, Ecologique, Legal), I’analyse TECOP 
(Technique, Ecologique, Commercial, Operationnel, Politique), ou I’analyse VUCA, qui signifie Volatility (Volatility), Uncertainty 
(Incertitude), Complexity (Complexity) et Ambiguity (Ambiguite). 

11.2.2.6 REUNIONS 

Pour entreprendre I’identification des risques, I’equipe projet peut organiser une reunion specialises (souvent appelee 
un atelier sur le risque). La majority des ateliers sur le risque incluent une sorte de brainstorming (voir la section 4.1.2.2). 
Toutefois, d’autres techniques d’identification des risques peuvent etre integrees en fonction du niveau du processus 
de risque defini dans le plan de gestion des risques. Faire appel a un facilitateur competent permettra de renforcer 
I’efficacite de la reunion. II est egalement essentiel de veiller a ce que les bonnes personnes participent a I'atelier sur 
le risque. Pour les projets plus importants, il peut etre approprie d’inviter le sponsor du projet, des experts specialises 
dans le domaine, des vendeurs, des representants du client ou d’autres parties prenantes du projet. Pour les projets plus 
petits, les ateliers sur le risque peuvent se limiter a un sous-groupe de I’equipe projet. 
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11.2.3 IDENTIFIER LES RISQUES : DONNEES DE SORTIE 


11.2.3.1 REGISTRE DES RISQUES 

Le registre des risques regroupe les details des risques individuels identifies du projet. Les resultats des processus 
Effectuer I'analyse qualitative des risques, Planifier les reponses aux risques, Executer les reponses aux risques et 
MaTtriser les risques sont consignes dans le registre des risques, car ces processus sont menes tout au long du projet. 
Le registre des risques peut contenir des informations limitees ou exhaustives sur les risques en fonction des variables 
du projet, telles que la taille et la complexity 

A la fin du processus Identifier les risques, le contenu du registre des risques peut notamment inclure les 
elements suivants: 

♦ Liste des risques identifies. Dans le registre des risques, un identifiant unique est attribue a chaque risque 
individuel du projet. Les risques identifies sont decrits selon le niveau de detail requis pour garantir une 
comprehension sans equivoque. Un enonce de risque structure peut etre utilise afin de distinguer les risques de 
leur(s) cause(s) et de leur(s) effet(s). 

♦ Charges potentieis de risques. Si un charge potentiel de risque a ete identifie au cours du processus Identifier 
les risques, il est enregistre dans le registre des risques. II sera confirme au cours du processus Effectuer 
I’analyse qualitative des risques. 

♦ Liste des reponses potentielles aux risques. Si une reponse potentielle aux risques a ete identifier au cours 
du processus Identifier les risques, elle est enregistree dans le registre des risques. Elle sera confirmee au cours 
du processus Planifier les reponses aux risques. 

Des donnees supplementaires peuvent etre consignees pour chaque risque identifie, en fonction du format du registre 
des risques specifie dans le plan de gestion des risques. Parmi ces donnees, on peut citer un court intitule de risque, 
la categorie de risque, le statut de risque actuel, une ou plusieurs causes, un ou plusieurs effets sur les objectifs, les 
declencheurs de risque (des evenements ou des conditions indiquant qu’un risque est sur le point de se produire), la 
reference WBS des activites concernees et des informations temporelles (le moment ou le risque a ete identifie, le moment 
ou le risque pourrait se produire, le moment ou le risque ne sera plus important et le delai pour prendre une mesure). 


417 



11.2.3.2 RAPPORT SUR LES RISQUES 


Le rapport sur les risques presente des informations sur les sources du risque global du projet et recapitule les 
risques individuels identifies du projet. II est elabore progressivement tout au long du processus de gestion des risques 
du projet. Les resultats des processus Effectuer I'analyse qualitative des risques, Effectuer I'analyse quantitative des 
risques, Planifier les reponses aux risques, Executer les reponses aux risques et MaTtriser les risques sont egalement 
consigners dans le rapport sur les risques des que ces processus sont termines. A la fin du processus Identifier les 
risques, le contenu du rapport sur les risques peut inclure notamment les elements suivants : 

♦ les sources du risque global du projet, indiquant les facteurs d’exposition au risque global du projet les plus importants; 

♦ la synthese des risques individuels identifies du projet, tels que le nombre de menaces et d’opportunites 
identifies mais aussi la repartition des risques entre les categories de risques, les metriques et les tendances. 

Le rapport sur les risques peut inclure encore d'autres informations, en fonction des exigences de communication 
specifies dans le plan de gestion des risques. 

11.2.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Au cours du processus Identifier is risques, de 
nouvelles hypotheses peuvent etre formuies, de nouvelles contraintes peuvent etre identifies et is hypotheses 
ou is contraintes existantes peuvent etre passees en revue et changees. Le journal des hypotheses doit etre mis 
a jour afin d'inclure ces nouvelles informations. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter doit etre mis a 
jour afin de collecter tout nouveau point a traiter non couvert ou les changements apportes aux points a traiter 
actuellement enregistres. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour afin d'inclure des informations sur les techniques qui se sont averees efficaces dans I'identification 
des risques, et ainsi d’ameliorer la performance lors de phases ulterieures ou d’autres projets. 
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11.3 EFFECTUER L’ANALYSE QUALITATIVE DES RISQUES 


Effectuer I'analyse qualitative des risques est le processus qui consiste a hierarchiser les risques individuels du 
projet afin de les analyser ou de les exploiter ulterieurement en evaluant leur probabilite d’occurrence et leur impact 
ainsi que d’autres caracteristiques. L’interet principal de ce processus est qu'il concentre les efforts sur les risques 
a priorite elevee. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques et 
les donnees de sortie de ce processus sont presentes a la figure 11 -8. La figure 11 -9 presente le diagramme de flux 
de donnees du processus. 


Effectuer I’analyse qualitative des risques 


Donnees d’entree V Outils et techniques ■ Donnees de sortie 


1 Elaborer le plan 
de management du projet 

• Plan de gestion des risques 
.2 Documents du projet 

• Journal des hypotheses 

• Registre des risques 

• Registre des parties 
prenantes 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V___/ 


.1 Jugement a dire d’expert 
.2 Collecte des donnees 

• Entretiens 

.3 Analyse des donnees 

• Evaluation de la qualite 
des donnees relatives 
aux risques 

• Evaluation de la probabilite 
et de I’impact des risques 

• Evaluation d'autres 
parametres lies aux risques 

.4 Competences 

interpersonnelles et d’equipe 

• Facilitation 

.5 Categorisation des risques 
.6 Representation des donnees 

• Matrice de probabilite et 
d'impact 

• Diagrammes hierarchiques 
.7 Reunions 


.1 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des risques 

• Rapport sur les risques 

v ___y 


Figure 11-8. Effectuer I’analyse qualitative des risques: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


Plan de management du projet 
• Plan de gestion des risques 


Documents 
du projet 


Documents du projet 

• Journal des hypotheses 

• Registre des risques 

• Registre des parties prenantes 


Entreprise/ 

Organisation 

• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


11.3 

Effectuer 

I’analyse qualitative 
des risques 


Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des risques 

• Rapport sur les risques 


Documents 
du projet 


Figure 11-9. Effectuer I’analyse qualitative des risques: diagramme de flux de donnees 


Le processus Effectuer I’analyse qualitative des risques permet d'evaluer la priorite des risques individuels identifies 
du projet sur la base de leur probability d’occurrence, de leur impact sur les objectifs du projet, si le risque survient, 
et d'autres facteurs. Ces evaluations sont subjectives, car elles reposent sur les perceptions du risque de I’equipe 
projet et d’autres parties prenantes. Une evaluation efficace requiert done une identification explicite et la gestion des 
approches du risque des participants cles dans le cadre du processus Effectuer I’analyse qualitative des risques. La 
perception du risque introduit un parti pris dans revaluation des risques identifies. II convient done de faire attention 
a identifier ce parti pris et a le corriger. Si I’on recourt a un facilitateur pour soutenir le processus Effectuer I'analyse 
qualitative des risques, I’un de ses roles essentiels consistera a I utter contre les partis pris. Une evaluation de la qualite 
des informations disponibles, concernant les risques individuels du projet, aide a clarifier revaluation de I’importance 
de chaque risque pour le projet. 
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Le processus Effectuer I'analyse qualitative des risques permet d’etablir les priorites relatives aux risques individuels 
du projet pour le processus Planifier les reponses aux risques. II identifie un charge de risque pour chaque risque qui 
assumera la responsabilite de planifier une reponse aux risques appropriee et de garantir son execution. Le processus 
Effectuer I’analyse qualitative des risques jette egalement les bases du processus Effectuer I’analyse quantitative des 
risques, si ce processus est necessaire. 

Le processus Effectuer I'analyse qualitative des risques est effectue a intervalles reguliers au cours du cycle de vie du 
projet, comme defini dans le plan de gestion des risques du projet. Souvent, dans un environnement de developpement 
agile, le processus Effectuer I’analyse qualitative des risques est mene avant le debut de chaque iteration. 


11.3.1 EFFECTUER L’ANALYSE QUALITATIVE DES RISQUES : DONNEES D’ENTREE 

11.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure notamment le plan de 
gestion des risques decrit a la section 11.1.3.1. Les roles et les responsabilites lies a la gestion des risques, les budgets 
de la gestion des risques, les activites de I’echeancier pour la gestion des risques, les categories de risques (souvent 
definies dans un organigramme des risques), les definitions de la probability et de I'impact, la matrice de probability et 
d’impact mais aussi les seuils de risque des parties prenantes sont des elements particulierement interessants dans 
ce processus. Ces donnees d’entree sont generalement adaptees au projet dans le cadre du processus Planifier la 
gestion des risques. Si elles ne sont pas disponibles, elles peuvent etre developpees au cours du processus Effectuer 
I’analyse qualitative des risques et presentees au sponsor du projet afin d’etre approuvees avant utilisation. 

11.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses est utilise pour identifier, 
gerer et martriser les hypotheses et contraintes majeures pouvant affecter le projet. Elles peuvent permettre 
d’evaluer la priority des risques individuels du projet. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques contient des details sur chacun 
des risques individuels identifies du projet qui seront evalues dans le cadre du processus Effectuer I'analyse 
qualitative des risques. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. II detaille les parties prenantes du projet qui 
peuvent etre designees en quality de charges de risque. 
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11.3.1.3 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Effectuer 
Panalyse qualitative des risques, on peut citer: 

♦ les etudes de projets similaires menees dans le secteur; 

♦ les documents publies, notamment les bases de donnees de risques ou les checklists vendues dans le commerce. 

11.3.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Effectuer [analyse qualitative des 
risques, on peut citer les informations issues de projets acheves similaires. 


11.3.2 EFFECTUER L’ANALYSE QUALITATIVE DES RISQUES : OUTILS ET TECHNIQUES 

11.3.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation aux themes suivants : 

♦ les projets anterieurs similaires ; 

♦ [analyse qualitative des risques. 

Un jugement a dire d’expert est souvent obtenu dans le cadre d’ateliers diriges sur les risques ou d’entretiens. La 
possibility d’un parti pris des experts devrait etre prise en compte dans le cadre de ce processus. 

11.3.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
entretiens. II est possible d’utiliser des entretiens structures ou semi-structures (voir la section 5.2.2.2) pour evaluer 
la probability et les impacts des risques individuels du projet, ainsi que d’autres facteurs. L’enqueteur doit favoriser 
un environnement de confiance et de confidentiality mais aussi mener I'entretien en encourageant les evaluations 
honnetes et impartiales. 
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11.3.2.3 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Evaluation de la qualite des donnees relatives aux risques. L’evaluation de la qualite des donnees relatives 
aux risques permet d’estimer le niveau a partir duquel les donnees sur les risques individuels du projet sont 
exactes etfiables pour servir de base a I’analyse qualitative des risques. L’utilisation de donnees de faible qualite 
peut conduire a une analyse qualitative des risques qui sera peu utile au projet. Si la qualite des donnees est 
inacceptable, il sera necessaire de recueillir des donnees de meilleure qualite. La qualite des donnees relatives 
aux risques peut etre evaluee via un questionnaire mesurant les perceptions qu'ont les parties prenantes du 
projet des differentes caracteristiques, parmi lesquelles I’exhaustivite, I’objectivite, la pertinence et la ponctualite. 
Une moyenne ponderee des caracteristiques selectionnees de la qualite des donnees peut alors etre generee afin 
de donner une note de qualite globale. 

♦ Evaluation de la probability et de I’impact des risques. L’evaluation de la probability des risques examine la 
vraisemblance qu’un risque specifique survienne. L’evaluation de I’impact des risques prend en consideration 
I’effet potentiel d’un ou de plusieurs objectifs du projet, comme I'echeancier, le cout, la qualite ou la performance. 
Les impacts seront negatifs pour les menaces et positifs pour les opportunity. La probability et I’impact sont 
evalues pour chaque risque individuel du projet identifie. Les risques peuvent etre evalues au cours d’entretiens 
ou de reunions, avec des participants selectionnes pour leur connaissance des types de risques enregistres dans 
le registre des risques. Les membres de I’equipe projet, et des personnes competentes externes au projet, y 
participent. La probability de chaque risque et son impact sur chaque objectif sont evalues au cours des entretiens 
ou des reunions. On peut s’attendre a des differences entre les niveaux de probability et d’impact pergus par 
les parties prenantes. Ensuite, ces differences doivent etre prises en compte. L’explication detaillee, y compris 
les hypotheses justifiant les niveaux attribues, est egalement enregistree. Les probabilites et les impacts des 
risques sont notes en fonction des definitions fournies par le plan de gestion des risques (voir le tableau 11-1). 
Les risques dont la probability et I'impact sont faibles seront inclus dans le registre des risques en tant que liste 
de veille pour un suivi futur. 

♦ Evaluation d’autres parametres lies aux risques. L'equipe projet peut prendre en compte d’autres 
caracteristiques liees au risque (en plus de la probability et de I’impact) lorsqu’elle classe les risques individuels 
du projet par ordre de priority afin de les analyser et d’executer des reponses ulterieurement. Ces caracteristiques 
comprennent, entre autres les elements suivants : 
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■ Urgence. Delai dans lequel une reponse au risque doit etre executee pour etre efficace. Un delai court indique 
une grande urgence. 

■ Proximite dans le temps. Delai avant que le risque ne puisse avoir un impact sur un ou plusieurs des objectifs 
du projet. Un delai court indique une grande proximite. 

■ Inactivity. Delai qui peut s’ecouler apres I’apparition d’un risque et avant que son impact ne soit decouvert. 
Un delai court indique une faible inactivity. 

■ Souplesse. Facility avec laquelle le charge de risque (ou I’organisation chargee du risque) peut gerer 
I’occurrence ou I’impact d’un risque. Si la gestion est facile, la souplesse est grande. 

■ Controlabilite. Niveau auquel le charge de risque (ou I’organisation chargee du risque) est capable de controler 
la consequence du risque. Si la consequence peut etre facilement controlee, la controlabilite est grande. 

■ Detectabilite. Facility avec laquelle les resultats du risque qui se realise, ou qui est sur le point de se realiser, 
peuvent etre detectes et reconnus. Si I'occurrence du risque peut etre detectee facilement, la detectabilite 
est grande. 

■ Connectivity. Mesure dans laquelle le risque est lie a d’autres risques individuels du projet. Si un risque est 
connecte a de nombreux autres risques, la connectivity est grande. 

■ Impact strategique. La possibility que le risque ait un effet positif ou negatif sur les objectifs strategies 
de I’organisation. Si le risque a un effet majeur sur les objectifs strategies, I’impact strategique est grand. 

■ Contiguity. Degre a partir duquel un risque est pergu important par une ou plusieurs parties prenantes. Si un 
risque est pergu comme tres important, la contiguity est elevee. 

La consideration de certaines de ces caracteristiques peut permettre de classer les risques selon des priorites mieux 
etablies qu’il n’est possible de le faire en evaluant uniquement la probability et I’impact. 

11.3.2.4 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment 
la facilitation (voir la section 4.1.2.3). La facilitation permet d’ameliorer I’efficacite de I'analyse qualitative des risques 
individuels du projet. Un facilitateur competent peut aider les participants a rester concentres sur latache d’analyse des 
risques, a suivre exactement la methode associee a la technique, a s'accorder sur les evaluations de la probability et de 
I’impact, a identifier et a surmonter les sources de parti pris mais aussi a resoudre tout desaccord eventuel. 
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11.3.2.5 CATEGORISATION DES RISQUES 


Les risques du projet peuvent etre categorises par source de risque (par exemple, en utilisant I'organigramme des 
risques ; voir la figure 11 -4), par domaine concerne du projet (par exemple, en utilisant I’organigramme des travaux 
du projet (WBS); voir les figures 5-12, 5-13 et 5-14) ou selon toute autre categorie utile (par exemple, une phase 
du projet, le budget du projet ou encore les roles et responsabilites), en vue de determiner les secteurs du projet 
qui sont le plus exposes aux effets de I’incertitude. Les risques peuvent aussi etre categorises en fonction de leurs 
causes originelles communes. Les categories de risque qui peuvent etre utilisees pour le projet sont definies dans le 
plan de gestion des risques. 

Grace au regroupement des risques par categories, il est possible d’elaborer des reponses aux risques plus 
efficaces. Cela peut etre obtenu en ciblant I'attention et les efforts sur les domaines les plus exposes aux risques ou 
en developpant des reponses aux risques generiques afin de traiter des groupes de risques lies. 

11.3.2.6 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Matrice de probabilite et d’impact. Une matrice de probabilite et d'impact est une grille de representation 
graphique de la probabilite d’occurrence de chaque risque et de son impact sur les objectifs du projet si ce risque 
se materialise. Cette matrice specifie les combinaisons de probabilite et d’impact qui permettent de diviser 
les risques individuels du projet en groupes de priorite (voir figure 11-5). Les risques peuvent etre classes par 
ordre de priorite pour effectuer une analyse supplemental et planifier des reponses aux risques sur la base 
de leur probabilite et de leurs impacts. La probabilite d'occurrence de chaque risque individuel du projet est 
evaluee ainsi que son impact sur un ou plusieurs des objectifs du projet s’il survient, grace aux definitions de la 
probabilite et de I’impact pour le projet, tel que specifie dans le plan de gestion des risques. Un niveau de priorite 
est attribue a chaque risque individuel du projet en fonction de la combinaison de sa probabilite et de son impact 
evalues a I'aide d’une matrice. 

Une organisation peut evaluer un risque separement pour chaque objectif (par exemple, le cout, le temps et le 
perimetre) en utilisant une matrice de probabilite et d'impact distincte pour chaque objectif. Par ailleurs, elle 
peut elaborer des moyens pour determiner un niveau de priorite global pour chaque risque. Cela peut etre fait 
soit en combinant les evaluations pour differents objectifs, soit en prenant le niveau de priorite le plus eleve, 
independamment de I'objectif concerne. 

♦ Diagrammes hierarchiques. Lorsque des risques ont ete classes par ordre de priorite a I’aide de plus de deux 
parametres, la matrice de probabilite et d’impact ne peut etre utilisee, et d’autres representations graphiques 
sont necessaires. Par exemple, un diagramme a bulles est un diagramme a trois dimensions, dans lequel chaque 
risque est represente sous la forme d’un disque (une bulle) et les trois parametres sont represents par la valeur 
de I’axe x, la valeur de I’axe y et la taille des bulles. Un exemple de diagramme a bulles est donne a la figure 11-10 
dans lequel la detectabilite et la proximite sont representees sur les axes x et y et la valeur de I'impact par la 
taille des bulles. 
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Taille de bulle = valeur de I’impact 



Les grandes 
bulles dans 
cette zone sont 
inacceptables 


Les petites bulles Detectabilite 

dans cette zone 
sont acceptables 


Figure 11-10. Exemple de diagramme a bulles montrant la detectabilite, la proximite et la valeur de I’impact 


11.3.2.7 REUNIONS 

Pour entreprendre I’analyse qualitative des risques, I’equipe projet peut organiser une reunion specialist (souvent 
appelee un atelier sur le risque) dediee a I’examen des risques identifies individuels du projet. Les objectifs de cette 
reunion incluent la revue des risques precedemment identifies, revaluation de la probabilite et des impacts (et 
eventuellement d’autres parametres de risque), la categorisation et la priorisation. Un charge de risque sera attribue a 
chaque risque individuel du projet dans le cadre du processus Effectuer (’analyse qualitative des risques. II sera charge 
de planifier une reponse au risque et de rendre compte de I’avancement de la gestion du risque, La reunion peut 
commencer par la revue et la confirmation des echelles de probabilite et d’impact a utiliser pour I'analyse. Elle peut 
egalement identifier des risques supplementaires au cours de la discussion, lesquels seront consignes pour analyse. 
Faire appel a un facilitateur competent permettra de renforcer I'efficacite de la reunion. 
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11.3.3 EFFECTUER L’ANALYSE QUALITATIVE DES RISQUES : DONNEES DE SORTIE 


11.3.3.1 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Au cours du processus Effectuer I’analyse qualitative 
des risques, de nouvelles hypotheses peuvent etre formulees, de nouvelles contraintes peuvent etre identifies 
et les hypotheses ou les contraintes existantes peuvent etre passees en revue et modifies. Le journal des 
hypotheses doit etre mis a jour afin d’inclure ces nouvelles informations. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter doit etre mis a 
jour afin de collecter tout nouveau point a traiter non couvert ou les changements apportes aux points a traiter 
actuellement enregistres. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour afin d'inclure les 
nouvelles informations generees au cours du processus Effectuer I’analyse qualitative des risques. Les mises 
a jour du registre des risques peuvent inclure les evaluations de la probabilite et des impacts de chacun des 
risques, le classement ou la notation des risques, le charge de risque designe, les informations sur I’urgence des 
risques, ou la categorie des risques ainsi qu’une liste de veille des risques de faible probabilite ou des risques 
exigeant davantage d’analyse. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques est mis a jour afin de refleter 
les risques individuels du projet les plus importants (generalement ceux dont la probabilite et I’impact sont les plus 
eleves), ainsi que la liste de tous les risques identifies classes par ordre de priorite et une conclusion recapitulative. 
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11.4 EFFECTUER L’ANALYSE QUANTITATIVE DES RISQUES 


Effectuer I’analyse quantitative des risques est le processus qui consiste a analyser de fagon mesurable I’effet 
combine des risques individuels identifies du projet et des autres sources d’incertitudes sur I’ensemble des objectifs 
globaux du projet. L'interet principal de ce processus est qu’il quantifie I'exposition au risque global du projet. II peut 
aussi fournir des informations quantitatives sur les risques supplementaires afin de contribuer a la planification de la 
reponse aux risques. Ce processus n’est pas requis pour chaque projet. Cependant, lorsqu’il est utilise, il est effectue tout 
au long du projet. Les donnees d’entree et de sortie de ce processus sont presentees a la figure 11 -11. La figure 11-12 
presente le diagramme de flux de donnees du processus. 


Effectuer l’analyse quantitative des risques 


Donnees d’entree 


.1 Elaborer le plan de 
management du projet 

• Plan de gestion des risques 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

.2 Documents du projet 

• Journal des hypotheses 

• Base des estimations 

• Estimations de couts 

• Previsions de couts 

• Estimations de durees 

• Liste des jalons 

• Besoins en ressources 

• Registre des risques 

• Rapport sur les risques 

• Previsions de I'echeancier 
.3 Facteurs environnementaux 

de I'organisation 
.4 Actifs organisationnels 

v___y 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Collecte des donnees 

• Entretiens 
.3 Competences 

interpersonnelles et d'equipe 

• Facilitation 

.4 Representations 
de I'incertitude 
.5 Analyse des donnees 

• Simulations 

• Analyse de sensibilite 

• Analyse par arbre 
de decision 

• Diagrammes d'influence 

V _/ 


Donnees de sortie 


.1 Mises a jour des documents 
du projet 

• Rapport sur les risques 

V ___ 


Figure 11-11. Effectuer I’analyse quantitative des risques: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 



Plan de management du projet 

• Plan de gestion des risques 

• Reference de base du perimetre 

• Reference de base de I’echeancier 

• Reference de base des couts 


Documents 
du projet 


Documents du projet 

• Journal des hypotheses 

• Base des estimations 

• Estimations de couts 

• Previsions de couts 

• Estimations de durees 

• Liste des jalons 

• Besoins en ressources 

• Registre des risques 

• Rapport sur les risques 

• Previsions de I’echeancier 


Entreprise/ 

Organisation 


11.4 
Effectuer I’analyse 
quantitative 
des risques 


Mises a jour des documents 
du projet 

• Rapport sur les risques 


Documents 
du projet 


• Facteurs environnementaux 
de I’organisation 

• Actifs organisationnels 


Figure 11-12. Effectuer I’analyse quantitative des risques : diagramme de flux de donnees 


Le processus Effectuer I’analyse quantitative des risques n’est pas necessaire pour tous les projets. La realisation 
d’une analyse solide depend de la disponibilite de donnees de grande qualite relatives aux risques individuels du projet 
et aux autres sources d’incertitude, ainsi que d’une reference de base du projet fiable pour le perimetre, I’echeancier 
et le cout. L'analyse quantitative des risques requiert generalement un logiciel de risque specialise et une expertise en 
matiere de developpement et d'interpretation des modeles de risque. En outre, cette analyse requiert du temps et genere 
un cout supplemental. L’utilisation d’une analyse quantitative des risques pour un projet sera specifiee dans le plan de 
gestion des risques du projet. Elle est probablement plus appropriee pour les projets d’envergure ou complexes, les projets 
strategiquement importants, les projets pour lesquels il s’agit d’une exigence contractuelle ou les projets au sein desquels 
une partie prenante principale I’exige. L’analyse quantitative des risques est la seule methode fiable qui permet d’evaluer 
le risque global du projet en estimant I’effet cumule, sur les resultats du projet, de tous les risques individuels du projet et 
des autres sources d’incertitude. 

Le processus Effectuer I’analyse quantitative des risques utilise des informations relatives aux risques individuels du 
projet, qui ont ete estimes par le processus Effectuer I’analyse qualitative des risques comme hautement susceptibles de 
nuire aux objectifs du projet. 

Les donnees de sortie du processus Effectuer I’analyse quantitative des risques sont utilisees en tant que donnees 
d’entree pour le processus Planifier les reponses aux risques, en particulier parce qu’elles recommandent des reponses au 
niveau du risque global et des principaux risques individuels du projet. Afin de determiner I’efficacite probable des reponses 
planifiees pour reduire I’exposition au risque global du projet, on peut egalement effectuer une analyse quantitative des 
risques en suivant le processus Planifier les reponses aux risques. 
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11.4.1 EFFECTUER L’ANALYSE QUANTITATIVE DES RISQUES : DONNEES D’ENTREE 


11.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques indique si 
I’analyse quantitative des risques est requise pour le projet. II detaille egalement les ressources disponibles pour 
I’analyse et la frequence attendue des analyses. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre decrit le 
point de depart a partir duquel I’effet des risques individuels du projet et d’autres sources d’incertitude sont evalues. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. La reference de base de I’echeancier 
decrit le point de depart a partir duquel on peut evaluer I’effet des risques individuels du projet et d’autres 
sources d’incertitude. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts decrit le point 
de depart a partir duquel on peut evaluer I’effet des risques individuels du projet et d’autres sources d’incertitude. 

11.4.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Les hypotheses peuvent constituer des donnees 
d’entree pour I’analyse quantitative des risques si elles sont considerees comme presentant un risque pour les 
objectifs du projet. L’effet des contraintes peut aussi etre modelise lors d’une analyse quantitative des risques. 

♦ Base des estimations. Elle est decrite dans les sections 6.4.3.2 et 7.2.3.2. La base des estimations utilisee 
dans la planification du projet peut se refleter dans la variabilite modelisee au cours du processus d’analyse 
quantitative des risques. Elle peut inclure des informations sur I’objectif de I'estimation, la classification, 
I’exactitude supposee, la methodologie et la source. 

♦ Estimations de couts. Elles sont decrites a la section 7.2.3.1. Les estimations de couts donnent le point de 
depart a partir duquel la variabilite des couts est evaluee. 

♦ Previsions de couts. Elles sont decrites a la section 7.4.3.2. Les previsions, telles que le cout du reste a faire 
(ETC) du projet, le cout estime a terminaison (EAC), le budget a terminaison (BAC) et I’indice de performance a 
terminaison du projet (TCPI), peuvent etre comparees aux resultats d’une analyse quantitative des risques lies au 
cout afin de determiner le niveau de confiance associe a la realisation de ces objectifs. 

♦ Estimations de durees. Elles sont decrites a la section 6.4.3.1. Les estimations de durees donnent le point de 
depart a partir duquel la variabilite de I’echeancier est evaluee. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. Les evenements significatifs au sein du projet definissent les 
objectifs de I’echeancier par rapport auxquels les resultats d’une analyse quantitative des risques de I’echeancier 
sont compares, afin de determiner le niveau de confiance associe a la realisation de ces objectifs. 
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♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Les besoins en ressources donnent le point de 
depart a partir duquel la variabilite est evaluee. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques comprend les details des risques 
individuels du projet a utiliser comme donnees d’entree pour I’analyse quantitative des risques. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques decrit les sources du risque 
global du projet et son statut actuel. 

♦ Previsions de I’echeancier. Elies sont decrites a la section 6.6.3.2. Les previsions peuvent etre comparees aux 
resultats d’une analyse quantitative des risques de I’echeancier pour determiner le niveau de confiance associe 
a la realisation de ces objectifs. 

11.4.1.3 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Effectuer 
Panalyse quantitative des risques, on peut citer: 

♦ les etudes de projets similaires menees dans le secteur; 

♦ les documents publies, notamment les bases de donnees de risques ou les checklists vendues dans le commerce. 

11.4.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Effectuer I’analyse quantitative des 
risques, on peut citer les informations provenant de projets similaires acheves. 


11.4.2 EFFECTUER L’ANALYSE QUANTITATIVE DES RISQUES : OUTILS ET TECHNIQUES 
11.4.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation aux themes suivants: 

♦ convert les informations sur les risques individuels du projet et les autres sources d'incertitude en donnees 
d’entree numeriques utilisees par le modele d’analyse quantitative des risques ; 

♦ selectionner la representation de I’incertitude la plus appropriee afin de modeliser des risques particuliers ou 
d’autres sources d’incertitude; 

♦ elaborer des techniques de modelisation adaptees au contexte du projet; 

♦ identifier les outils les mieux adaptes aux techniques de modelisation selectionnees; 

♦ interpreter les donnees de sortie de I'analyse quantitative des risques. 
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11.4.2.2 COLLECTE DES DONNEES 

Les entretiens (voir la section 5.2.2.2) peuvent etre utilises pour generer des donnees d’entree pour I'analyse 
quantitative des risques en s’appuyant sur des donnees d’entrees telles que les risques individuels du projet et d’autres 
sources d'incertitude. Cette technique est particulierement utile lorsqu’il est necessaire de faire appel a des experts. Au 
cours de I’entretien, I’interviewer doit favoriser un environnement de confiance et de confidentiality afin d’encourager 
les contributions honnetes et impartiales. 

11.4.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment 
la facilitation (voir la section 4.1.2.3). Un facilitateur competent est utile pour recueillir des donnees d’entree au cours 
d’un atelier dedie au risque reunissant les membres de I’equipe projet et d'autres parties prenantes. Les ateliers 
diriges peuvent renforcer I’efficacite en permettant de bien comprendre leur objectif, en forgeant un consensus entre 
les participants, en garantissant une attention continue axee sur la tache et en utilisant des approches creatives pour 
gerer les conflits ou les sources de parti pris. 

11.4.2.4 REPRESENTATIONS DE L’INCERTITUDE 

L’analyse quantitative des risques necessite d’integrer des donnees d’entree dans un modele d'analyse quantitative 
des risques, qui refletent les risques individuels du projet et les autres sources d'incertitude. 

Si la duree, le cout ou les besoins en ressources pour une activity planifiee sont incertains, on peut representer la 
plage des valeurs possibles dans le modele grace a une distribution de probability. Cette distribution peut prendre 
plusieurs formes. Les formes les plus couramment utilisees sont les distributions triangulaire, normale, logarithmique, 
beta, uniforme ou discrete. Lors de la selection d’une distribution de probabilite appropriee, il convient de prendre soin 
de refleter la gamme des valeurs possibles pour I’activite planifiee. 

Les risques individuels du projet peuvent etre couverts par les distributions de probabilite. Les risques peuvent 
egalement etre inclus dans le modele sous la forme de branches probabilistes, ou des activites optionnelles sont 
ajoutees au modele afin de representer I’impact du risque sur le temps et/ou le cout, le cas echeant. La possibility que 
ces activites se deroulent vraiment dans un test donne de simulation correspond a la probabilite du risque. Ces branches 
sont plus utiles pour les risques qui pourraient survenir independamment de toute activite planifiee. Lorsque les risques 
sont lies, par exemple, par une cause commune ou une dependence logique, la correlation est utilisee dans le modele 
pour indiquer cette relation. 

D'autres sources d’incertitude peuvent egalement etre representees au moyen des branches afin de decrire les 
chemins alternatifs dans le cadre du projet. 
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11.4.2.5 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Simulation. L'analyse quantitative des risques utilise un modele qui simule les effets combines des risques 
individuels du projet et des autres sources d'incertitude afin d’evaluer leur impact potentiel sur la realisation 
des objectifs du projet. Les simulations sont habituellement effectuees a I'aide de la methode de Monte-Carlo. 
Lorsqu’elle utilise la methode de Monte-Carlo pour le risque lie au cout, la simulation se fonde sur les estimations 
de cout du projet. Lorsqu’elle utilise la methode de Monte-Carlo pour le risque lie a I'echeancier, elle prend en 
consideration les estimations de duree et le diagramme de reseau de I’echeancier. Une analyse quantitative 
integree des risques lies au cout et a I'echeancier utilise ces deux types de donnees d’entree. Le resultat est un 
modele d’analyse quantitative des risques. 

Un logiciel informatique est utilise pour iterer le modele d’analyse quantitative des risques des milliers de fois. 
Les valeurs d’entree (les estimations de cout, les estimations de duree ou I’occurrence de branches probabilistes, 
par exemple) sont choisies au hasard pour chaque iteration. Les resultats represented le champ des possibles 
pour le projet (date de fin ou cout du projet a terminaison). Les donnees de sortie types incluent un histogramme 
presentant le nombre d'iterations au cours desquelles un resultat particulier est obtenu a partir de la simulation 
ou une distribution de probability cumulative (courbe en S) represented la probability d’obtenir un resultat 
particulier ou moins. La figure 11-13 montre un exemple de courbe en S representant le resultat d’une analyse 
des risques de cout fondee sur la methode Monte-Carlo. 


Plage d'incertitude 



2,0 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 

millions $ millions $ millions $ millions $ millions $ millions $ millions $ millions $ millions $ 

Cout total du projet prevu 


Figure 11-13. Exemple de courbe en S resultant d’une analyse quantitative des risques de cout 
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Pour une analyse quantitative des risques lies a I'echeancier, il est egalement possible d'effectuer une analyse 
de criticite qui determine les elements du modele de risque ayant I'effet le plus important sur le chemin critique 
du projet. Un indice de criticite est calcule pour chaque element du modele de risque. II indique la frequence a 
laquelle les elements apparaissent sur le chemin critique au cours de la simulation, generalement exprimee en 
pourcentage. Le resultat d’une analyse de criticite permet a I'equipe projet de cibler les efforts de planification 
des reponses aux risques sur les activites dont I’effet potentiel sur la performance globale de I’echeancier du 
projet est le plus important. 

♦ Analyse de sensibilite. L'analyse de sensibilite permet de determiner les risques individuels du projet ou les autres 
sources d’incertitude qui ont I’impact potentiel le plus important sur les resultats du projet. Elle fait la correlation 
entre les variations des resultats du projet et des elements du modele d’analyse quantitative des risques. 

Une representation type de l’analyse de sensibilite est le diagramme tornado, qui presente le coefficient de 
correlation calcule pour chaque element du modele d’analyse quantitative des risques pouvant influencer le 
resultat du projet. Ces elements peuvent inclure, entre autres, les risques individuels du projet, les activites du 
projet a haut degre de variability ou des sources d’ambiguite specifiques. Ms sont classes selon leur force de 
correlation, par ordre decroissant, ce qui donne cette forme type de tornade. La figure 11-14 donne un exemple 
de diagramme tornado. 



- 0,2 - 0,1 0 0,1 0,2 0,3 0,4 0,5 

Correlation avec la duree du projet 


Figure 11-14. Exemple de diagramme tornado 
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♦ Analyse par arbre de decision. Les arbres de decision sont utilises pour aider a choisir le meilleur plan d'action. 
Dans I’arbre de decision, les alternatives dans le cadre du projet sont illustrees par des branches representant 
differentes decisions ou differents evenements pouvant chacun avoir des couts et des risques individuels de 
projet associes (y compris les menaces et les opportunites). Les extremites des branches represented le resultat 
final d’un chemin particulier, qui peut etre negatif ou positif. 

L’arbre de decision est evalue en calculant la valeur monetaire attendue pour chaque branche, ce qui permet de 
selectionner le chemin optimal. La figure 11-15 donne un exemple d'arbre de decision. 


Definition 
de la decision 

Noeud de la decision 

Noeud de chance 

Valeur 

du chemin net 

Decision a prendre 

Donnee d’entree: Cout de chaque decision 

Donnee de sortie: Decision prise 

Donnee d’entree: Probability de scenario, 
recompense le cas echeant 

Donnee de sortie: Valeur monetaire 
Prevue (EMV) 

Calcul: Benefices moins 
Couts sur le Chemin 



Remarque 1: L’arbre de decision montre comment prendre une decision entre les differentes strategies de capital (representees 
comme des «« noeuds de decision ») lorsque I’environnement comprend des elements incertains (represents comme 
des « noeuds de chance »). 

Remarque 2: lei, il s'agit de decider d’investir 120 millions de dollars americains pour construire une nouvelle usine ou d'investir 
50 millions de dollars americains pour moderniser I’usine existante. Pour chaque decision, la demande (qui est 
incertaine et represente done un « nceud de chance ») doit etre prise en compte. Par exemple, une forte demande 
genere 200 millions de dollars de recettes avec la nouvelle usine mais seulement 120 millions de dollars pour I'usine 
modernisee, sans doute en raison des limites de capacite de I’usine modernisee. L’extremite de chaque branche 
montre I’effet net des benefices moins les couts. Pour chaque branche de decision, tous les effets sont ajoutes (voir 
zones grisees) afin de determiner la valeur monetaire prevue (Expected Monetary Value, EMV) de la decision. II ne faut 
pas oublier de tenir compte des couts d'investissement. Selon les calculs dans les zones grisees, I’usine modernisee 
a une EMV superieure de 46 millions de dollars, comme I’EMV de la decision globale. (Ce choix represente aussi 
le risque le plus faible, evitant le pire resultat possible d'une perte de 30 millions de dollars). 


Figure 11-15. Exemple d’arbre de decision 
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♦ Diagrammes d’influence. Les diagrammes d’influence sont des aides graphiques qui permettent de prendre 
des decisions en cas d'incertitude. Un diagramme d’influence represente un projet ou une situation au sein du 
projet sous la forme d’un ensemble d’entites, de resultats et d’influences ainsi que les relations et les effets 
entre chacun d’eux. Si un element du diagramme d’influence est incertain, car il existe des risques individuels 
ou d’autres sources d'incertitude, il peut etre represente dans le diagramme d’influence a I’aide de plages de 
valeurs ou de distributions de probabilites. Le diagramme d'influence est ensuite evalue grace a une technique 
de simulation, comme la methode de Monte-Carlo, pour indiquer les elements qui ont le plus d’influence sur 
les principaux resultats. Les resultats d’un diagramme d’influence sont similaires a ceux des autres methodes 
d’analyse quantitative des risques, notamment les courbes en S et les diagrammes tornado. 


11.4.3 EFFECTUER L’ANALYSE QUANTITATIVE DES RISQUES : DONNEES DE SORTIE 

11.4.3.1 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees de sortie pour ce processus, 
figure le rapport sur les risques decrit a la section 11.2.3.2. Le rapport sur les risques sera mis a jour afin de refleter les 
resultats de I’analyse quantitative des risques. En regie generate, il inclut les elements suivants : 

♦ Evaluation de I’exposition au risque global du projet. Le risque global du projet transparaTt dans deux 
grandes mesures: 

■ les chances de reussite du projet, indiquees par la probability que le projet atteigne ses objectifs cles (par 
exemple I’echeance requise ou les jalons intermediaires, la cible requise en termes de cout, etc.), au vu des 
risques individuels identifies et des autres sources d'incertitude; 

■ le degre de variability inherent au reste du projet au moment de I’analyse, indique par la plage des resultats 
possibles pour le projet. 

♦ Analyse probabiliste detaillee du projet. Les principales donnees de sortie de I’analyse quantitative des risques, 
telles que les courbes en S, les diagrammes tornado et I’analyse de criticite, sont presentees accompagnees 
d’une interpretation narrative des resultats. Parmi les eventuels resultats detailles d’une analyse quantitative des 
risques, on peut citer: 

■ le montant de la reserve pour alea necessaire a la garantie d’un niveau de confiance specifie; 

■ I’identification des risques individuels du projet ou des autres sources d’incertitude ayant I’effet le plus 
important sur le chemin critique du projet; 

■ les principaux facteurs du risque global du projet, ayant la plus grande influence sur I’incertitude des resultats 
du projet. 

♦ Liste des risques individuels du projet classes par ordre de priority. Cette liste comprend les risques 
individuels du projet qui represented la plus grande menace ou la plus grande opportunity pour le projet, comme 
indique par I'analyse de sensibility. 

♦ Tendances des resultats de I’analyse quantitative des risques. L’analyse etant repetee a differents moments 
au cours du cycle de vie du projet, des tendances apparaissent et permettent de planifier les reponses aux risques. 

♦ Reponses aux risques recommandees. Le rapport sur les risques peut presenter des suggestions de reponses 
au niveau de I'exposition au risque global du projet ou des principaux risques individuels, sur la base des resultats 
de I’analyse quantitative des risques. Ces recommandations formeront des donnees d’entree pour le processus 
Planifier les reponses aux risques. 
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11.5 PLANIFIER LES REPONSES AUX RISQUES 

Planifier les reponses aux risques est le processus qui consiste a developper des options, selectionner des strategies 
et convenir d’actions visant a gerer I’exposition au risque global du projet mais aussi a traiter chaque risque individuel 
du projet. L'interet principal de ce processus est qu’il identifie les moyens adequats pour gerer le risque global du 
projet et les risques individuels du projet. En outre, ce processus affecte les ressources et integre les activites dans 
les documents du projet et le plan de management du projet. Ce processus est execute tout au long du projet. Les 
donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 11-16. 
La figure 11-17 presente le diagramme de flux de donnees du processus. 


Planifier les reponses aux risques 


Donnees d’entree W Outils et techniques H Donnees de sortie 


1 Elaborer le plan 
de management du projet 

• Plan de gestion 
des ressources 

• Plan de gestion des risques 

• Reference de base 
des couts 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Affectations des membres 
de I'equipe projet 

• Calendriers des ressources 

• Registre des risques 

• Rapport sur les risques 

• Registre des parties 
prenantes 

.3 Facteurs environnementaux 
de I’organisation 
.4 Actifs organisationnels 

V___/ 


.1 Jugement a dire d’expert 
.2 Collecte des donnees 

• Entretiens 
.3 Competences 

interpersonnelles et d’equipe 

• Facilitation 

.4 Strategies pour les menaces 
.5 Strategies pour 
les opportunity 
.6 Strategies de reponse 
conditionnelles 
.7 Strategies pour le risque 
global du projet 
.8 Analyse des donnees 

• Analyse des alternatives 

• Analyse cout-benefice 
.9 Prise de decision 

• Analyse decisionnelle 
multicritere 

V_/ 


.1 Demandes de changement 
.2 Mises a jour du plan 

de management du projet 

• Plan de gestion 
de I'echeancier 

• Plan de gestion des couts 

• Plan de gestion de la qualite 

• Plan de gestion 
des ressources 

• Plan de gestion 

des approvisionnements 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

.3 Mises a jour des documents 

du projet 

• Journal des hypotheses 

• Previsions de couts 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Affectations des membres 
de I'equipe projet 

• Registre des risques 

• Rapport sur les risques 

V _ J 


Figure 11-16. Planifier les reponses aux risques: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 



Plan de management du projet 

• Plan de gestion des ressources 

• Plan de gestion des risques 

• Reference de base des couts 


Documents 
du projet 



Documents du projet 

• Registre des retours d’experience 

• Echeancier du projet 

• Organigramme des ressources 

• Calendriers des ressources 

• Registre des risques 

• Rapport sur les risques 

• Registre des parties prenantes 


Entreprise/ 

Organisation 


• Facteurs environnementaux 
de ['organisation 

• Actifs organisationnels 


• Demandes de changement 


4.6 


Effectuer 

la gestion integree 
des changements 


11.5 
Planifier 
les reponses 
aux risques 


Misesajourdu plan 
de management du projet 

• Plan de gestion de I’echeancier' 

• Plan de gestion des couts 

• Plan de gestion de la qualite 

• Plan de gestion des ressources 

• Plan de gestion des approvisionnements 

• Reference de base du perimetre 

• Reference de base de I’echeancier 

• Reference de base 
des couts 


Plan 

de management 
du projet 


Mises a jour des documents du projet 

• Journal des hypotheses 

• Previsions de couts 

• Registre des retours d’experience 

• Echeancier du projet 

• Affectations des membres de I’equipe projet 

• Registre des risques 

• Rapport sur les risques 


Documents 
du projet 


Figure 11-17. Planifier les reponses aux risques: diagramme de flux de donnees 
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Des reponses aux risques appropriees et efficaces peuvent minimiser les menaces individuelles, renforcer les 
opportunity individuelles et reduire I’exposition au risque global du projet. Des reponses aux risques inadaptees 
peuvent avoir I’effet inverse. Une fois que les risques ont ete identifies, analyses et classes par ordre de priorite, le 
charge de risque doit elaborer des plans visant a gerer chaque risque individuel du projet que I’equipe projet considere 
suffisamment important, soit a cause de la menace qu’il represente pour les objectifs du projet, soit en raison de 
I'opportunite offerte. Le chef de projet doit egalement reflechir a la fagon de reagir correctement au niveau de risque 
global du projet actuel. 

Les reponses aux risques doivent etre adaptees a I'importance du risque, rentables par rapport au defi a relever, 
realistes dans le contexte du projet, convenues partoutes les parties concernees et prises en charge par une personne 
responsable. II y a souvent lieu de choisir, parmi plusieurs options, la meilleure reponse au risque. La strategie, ou 
la combinaison de strategies, ayant le plus de chances de succes doit etre choisie pour chacun des risques. Des 
techniques de prise de decision structures peuvent etre utilisees pour choisir la reponse la plus appropriee. Pour les 
projets vastes ou complexes, il peut etre judicieux d’utiliser un modele d’optimisation mathematique ou une analyse 
des options reelles comme base d’une analyse economique plus solide des strategies possibles de reponse au risque. 

Des actions specifiques sont elaborees pour mettre en oeuvre la strategie de reponse au risque convenue, y compris 
des strategies principals et alternatives, selon le cas. II est possible d’elaborer un plan de contingence (ou plan de 
repli), mis en oeuvre si un risque accepte survient ou dans le cas ou la strategie choisie ne s’avererait pas entierement 
efficace. Les risques secondaires doivent egalement etre identifies. Ces risques surviennent en consequence directe de 
I’execution d’une reponse a un risque. Une reserve pour alea est souvent allouee pour les delais ou pour les couts. Si 
elle est etablie, elle peut inclure I’identification des conditions qui entraineraient son utilisation. 


11.5.1 PLANIFIER LES REPONSES AUX RISQUES : DONNEES D’ENTREE 

11.5.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources est utilise 
pour determiner la fagon dont les ressources allouees aux reponses aux risques convenues seront coordonnees 
avec les autres ressources du projet. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Ce processus utilise les roles et les responsabilites 
lies a la gestion des risques ainsi que les seuils de risque. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts comporte des 
informations sur la reserve pour aleas qui est allouee pour repondre aux risques. 
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11.5.1.2 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience sur les reponses 
aux risques efficaces utilisees lors des premieres phases du projet sont examines afin de determiner si des 
reponses similaires pourraient etre utiles pour la suite du projet. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L’echeancier est utilise pour determiner la fagon dont les 
reponses aux risques validees seront planifiees en parallele des autres activites du projet. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.2. Les affectations des membres 
de I’equipe projet peuvent montrer les ressources pouvant etre allouees aux reponses aux risques approuvees. 

♦ Calendriers des ressources. Ms sont decrits a la section 9.2.1.2. Les calendriers des ressources identifient le 
moment ou les ressources potentielles sont disponibles pour etre allouees aux reponses aux risques convenues. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques detaille les risques individuels du 
projet qui ont ete identifies et classes par ordre de priorite et qui necessitent une reponse. Le niveau de priorite de 
chaque risque peut permettre de selectionner les reponses appropriees aux risques. Par exemple, les menaces 
ou les opportunites a priorite elevee peuvent necessiter une action prioritaire et des strategies de reponse tres 
proactives. II se peut que les menaces et les opportunites dans la zone a priorite faible ne requierent pas d’action 
de gestion proactive, hormis leur inscription sur la liste de veille du registre des risques ou I’ajout d’une reserve 
pouralea. 

Le registre des risques identifie le charge de risque designe pour chaque risque. II peut egalement contenir les 
reponses aux risques preliminaires identifies prealablement au cours du processus de gestion des risques du 
projet. Le registre des risques peut fournir d’autres donnees sur les risques identifies qui peuvent aider a planifier 
les reponses aux risques, y compris les causes originelles, les facteurs de risque et les signaux divertissement, 
les risques necessitant des reponses a court terme et les risques pour lesquels la necessity d’une analyse 
supplemental a ete identifiee. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques presente le niveau actuel 
de I’exposition au risque global du projet qui permettra de selectionner la strategie de reponse au risque. II peut 
egalement enumerer les risques individuels du projet par ordre de priorite et fournir une autre analyse de la 
distribution des risques individuels du projet qui permettra de selectionner une reponse au risque. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes identifie les 
responsables potentiels des reponses aux risques. 
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11.5.1.3 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I'organisation susceptibles d'influencer le processus Planifier les reponses 
aux risques figurent, entre autres, I’appetence au risque et les seuils de risque des principales parties prenantes. 

11.5.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Planifier les reponses aux risques, 
on peut citer: 

♦ les modeles de plan de gestion des risques, le registre des risques et le rapport sur les risques ; 

♦ les bases de donnees historiques; 

♦ les archives des retours d’experience de projets similaires. 

11.5.2 PLANIFIER LES REPONSES AUX RISQUES : OUTILS ET TECHNIQUES 
11.5.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation aux themes suivants: 

♦ strategies de reponse aux menaces ; 

♦ strategies de reponse aux opportunites; 

♦ strategies de reponse conditionnelles ; 

♦ strategies de reponse au risque global du projet. 

Des donnees d’entree specialists peuvent etre obtenues aupres d’experts, par exemple lorsque des connaissances 
techniques specialists sont necessaires. 
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11.5.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees dans le cadre de ce processus figurent 
notamment les entretiens (voir la section 5.2.2.2). [.’elaboration des reponses aux risques individuels et au risque 
global du projet peut etre entreprise au cours d’entretiens structures ou semi-structures (voir la section 5.2.2.2) avec 
les charges de risque. D’autres parties prenantes peuvent egalement etre interrogees, si necessaire. L’interviewer doit 
favoriser un environnement de confiance et de confidentialite et mener I’entretien en encourageant les evaluations 
honnetes et impartiales. 

11.5.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment 
la facilitation (voir la section 4.1.2.3). La facilitation permet d’etre plus efficace dans [’elaboration des reponses aux 
risques individuels et au risque global du projet. Un facilitateur competent peut aider les charges de risque a comprendre 
le risque, a identifier et a comparer les differentes strategies de reponse au risque, a choisir une strategie de reponse 
appropriee mais aussi a identifier et a surmonter les sources de parti pris. 

11.5.2.4 STRATEGIES POUR LES MENACES 

Cinq strategies differentes peuvent etre prises en consideration pour gerer les menaces. 

♦ Escalader. L’escalade est appropriee lorsque I’equipe projet ou le sponsor du projet convient qu’une menace est 
exterieure au perimetre du projet ou que la reponse proposee depasse I’autorite du chef de projet. Les risques 
escalades sont geres au niveau du programme, au niveau du portefeuille ou de toute autre partie pertinente 
de [’organisation et non au niveau du projet. Le chef de projet determine qui doit etre informe de la menace et 
communique les details a cette personne ou partie de [’organisation. II est important que la responsabilite des 
menaces escaladees soit acceptee par la partie de ['organisation concernee. Les menaces sont generalement 
escaladees au niveau qui correspond aux objectifs susceptibles d’etre impactes si la menace se concretise. 
Les menaces escaladees ne sont pas suivies par I'equipe projet apres escalade, bien qu'elles puissent etre 
consignees dans le registre des risques pour information. 
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♦ Eviter. La strategie d'evitement des risques est menee par I’equipe projet pour eliminer la menace ou proteger 
le projet de son impact. Elle peut etre appropriee pour les menaces a priorite elevee presentant une forte 
probabilite d’occurrence et un impact negatif important. Elle peut impliquer de changer certains aspects du plan 
de management du projet ou I’objectif menace afin d’eliminer entierement la menace, en reduisant sa probabilite 
d’occurrence a zero. Le charge de risque peut egalement prendre des mesures pour isoler les objectifs du 
projet de I'impact du risque s’il survient. Les actions entrant dans le cadre de cette strategie peuvent inclure 
la suppression de la cause d’une menace, I'extension de I'echeancier, le changement de la strategie du projet 
ou la reduction du perimetre. Certains risques peuvent etre evites en clarifiant les exigences, en obtenant plus 
d’informations, en ameliorant la communication ou en acquerant de I'expertise. 

♦ Transferer. La strategie de transfert deplace la responsabilite d’une menace vers un tiers qui devra alors gerer le 
risque et supporter I’impact si la menace se concretise. Le transfert des risques implique souvent le versement 
d’une prime de risque a la partie qui assume la menace. Le transfert peut etre realise grace a un eventail de 
mesures, parmi lesquelles I’utilisation d’une assurance, de cautions, d’engagements, de garanties etautres. II est 
possible de recourir a des accords pour transferer la responsabilite de risques specifies a un tiers. 

♦ Attenuer. Une strategie d’attenuation des risques vise a reduire la probabilite d’occurrence et/ou I’impact 
d’une menace. Une mesure d’attenuation anticipee est souvent plus efficace qu’une tentative de reparation des 
dommages apres la realisation d’une menace. Adopter des processus moins complexes, effectuer davantage 
de tests ou choisir un vendeur plus fiable sont des exemples d’actions d’attenuation. L'attenuation peut requerir 
I’elaboration d’un prototype (voir la section 5.2.2.8) dans le but de reduire le risque lie au passage a grande 
echelle d’un modele d’etude d’un processus ou d’un produit. Lorsqu’il est impossible de reduire la probabilite, 
une reponse d’attenuation peut reduire I’impact, en ciblant les facteurs a I’origine de la severite. Par exemple, 
concevoir des systemes redondants peut attenuer I'impact d’un defaut du composant d’origine. 

♦ Accepter. L’acceptation du risque reconnaft I’existence d’une menace sans qu’aucune mesure proactive ne soit 
prise. Cette strategie peut etre appropriee pour les menaces a faible priorite. Elle peut egalement etre adoptee 
lorsqu’il n’est pas possible ni rentable de gerer une menace d’une autre fagon. L’acceptation peut etre active 
ou passive. La strategie d’acceptation active la plus repandue consiste a constituer une reserve pour alea, 
comprenant du temps, des moyens financiers ou des ressources pour traiter la menace si elle se concretise. 
L'acceptation passive ne demande aucune action proactive hormis la revue periodique de la menace afin de 
s'assurer qu'elle ne change pas de maniere significative. 
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11.5.2.5 STRATEGIES POUR LES OPPORTUNITY 


Cinq strategies differentes peuvent etre prises en consideration pour gerer les opportunity. 

♦ Escalader. Cette strategic de reponse au risque est appropriee lorsque I'equipe projet ou le sponsor du projet 
convient qu’une menace est exterieure au perimetre du projet ou que la reponse proposee depasse I’autorite du 
chef de projet. Les opportunity escaladees sont gerees au niveau du programme, au niveau du portefeuille ou de 
toute autre partie pertinente de I’organisation et non au niveau du projet. Le chef de projet determine qui doit etre 
informe de I’opportunite et communique les details a cette personne ou partie de I’organisation. II est important 
que la responsabilite des opportunity escaladees soit acceptee par la partie de I'organisation concernee. Les 
opportunity sont generalement escaladees au niveau qui correspond aux objectifs susceptibles d’etre touches si 
I’opportunite se concretise. Les opportunity escaladees ne sont pas suivies par I’equipe projet apres I’escalade, 
bien qu’elles puissent etre consignees dans le registre des risques pour information. 

♦ Exploiter. La strategie d’exploitation peut etre choisie pour les opportunity a priority elevee lorsque I’organisation 
souhaite s’assurer que I’opportunite est saisie. Cette strategie vise a saisir I'avantage associe a une opportunity 
particuliere en veillant a ce qu'elle se produise bel et bien et en augmentant la probability d’occurrence a 
100 %. L'affectation au projet des ressources les plus competentes de I'organisation en vue de reduire le delai 
d'achevement ou encore I'utilisation de nouvelles technologies ou des mises a niveau technologiques afin de 
reduire le cout et la duree sont des exemples d’exploitation des reponses. 

♦ Partager. La strategie de partage implique de transferer la responsabilite d’une opportunity a un tiers afin qu’il 
partage une partie de I’avantage si elle se concretise. II est important de bien choisir le nouveau responsable 
d’une opportunity partagee afin qu’il soit le mieux a meme de saisir I'opportunite en faveur du projet. Le partage 
des risques implique souvent le versement d’une prime de risque a la partie qui saisit I'opportunite. Des exemples 
d’action de partage de risques sont la formation de partenariats, d’equipes, de societes a finalite specifique ou 
de joint ventures. 

♦ Ameliorer. La strategie d’amelioration est utilisee pour accroTtre la probability et/ou I’impact d’une opportunity. 
Une mesure d’amelioration anticipee est souvent plus efficace que la tentative d’amelioration des benefices 
apres la realisation d’une opportunity. La probability d’occurrence d’une opportunity peut etre augmentee 
en concentrant I’attention sur les causes. Lorsqu’il est impossible d'augmenter la probability, une reponse 
d’amelioration peut augmenter I’impact, en visant les facteurs agissant sur I'importance de I'avantage potentiel. 
L’ajout de ressources a une activity pour qu’elle se termine plus tot est un exemple d’opportunites d’amelioration. 

♦ Accepter. La strategie d’acceptation d’une opportunity permet d’en beneficier sans qu’aucune mesure proactive 
ne soit prise. Cette strategie peut etre appropriee pour les opportunites a faible priority. Elle peut egalement 
etre adoptee lorsqu’il n’est pas possible ni rentable de gerer une opportunity d’une autre fagon. L’acceptation 
peut etre active ou passive. La strategie d’acceptation active la plus repandue consiste a constituer une reserve 
pour alea, comprenant du temps, des moyens financiers ou des ressources pour tirer profit de I’opportunite si 
elle se concretise. L’acceptation passive ne demande aucune action proactive hormis la revue periodique de 
I'opportunite afin de s'assurer qu'elle ne change pas de maniere significative. 
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11.5.2.6 STRATEGIES DE REPONSE CONDITIONNELLES 


Certaines reponses sont congues pour n’etre utilisees que si certains evenements se produisent. Pour certains 
risques, il est approprie que I’equipe projet elabore un plan de reponse qui sera execute, seulement sous certaines 
conditions predetermines, en supposant qu'elle en aura connaissance suffisamment tot pour mettre le plan en 
oeuvre. Les evenements declenchant la reponse conditionnelle, comme le fait de rater des jalons intermediates 
ou d’obtenir un niveau de priorite plus eleve aupres d’un vendeur, doivent etre definis et suivis. Les reponses aux 
risques, identifiees a I'aide de cette technique, sont souvent appelees plans de contingence ou plans de repli. Ms 
contiennent des evenements declencheurs identifies qui provoquent I’execution des plans. 

11.5.2.7 STRATEGIES POUR LE RISQUE GLOBAL DU PROJET 

Les reponses aux risques doivent etre planifiees et executees non seulement pour les risques individuels du projet 
mais aussi pour gerer le risque global du projet. Les memes strategies de reponse au risque qui sont utilisees pour gerer 
les risques individuels du projet peuvent etre appliquees au risque global du projet. 

♦ Eviter. Lorsque le niveau du risque global du projet est tres negatif et en dehors de seuils de risque convenus 
pour le projet, une strategie d’evitement peut etre adoptee. Elle implique de prendre des mesures visant a reduire 
I’effet negatif de I’incertitude pesant sur le projet dans son ensemble et de ramener le projet dans les limites des 
seuils. L’elimination des elements a haut risque du perimetre du projet est un exemple d’evitement a I’echelle 
globale du projet. Lorsqu’il est impossible de ramener le projet dans les limites des seuils, le projet peut etre 
annule. C'est le degre le plus extreme d'evitement du risque. Cette mesure ne doit etre utilisee que si le niveau 
global de la menace est et restera inacceptable. 

♦ Exploiter. Lorsque le niveau du risque global du projet est considerablement positif et en dehors de seuils 
de risque convenus pour le projet, une strategie d’exploitation peut etre adoptee. Cette strategie implique de 
prendre des mesures ciblees visant a saisir I’effet positif de I’incertitude pesant sur le projet dans son ensemble. 
L'ajout d’elements hautement benefiques au perimetre du projet en vue d'ajouter de la valeur ou des benefices 
en faveur des parties prenantes est un exemple d'exploitation a I'echelle globale du projet. De fagon alternative, 
les seuils de risque du projet peuvent etre modifies avec I’accord des principales parties prenantes afin de saisir 
I’opportunite. 

♦ Transferer/partager. Si le niveau du risque global du projet est eleve alors que I'organisation est incapable 
de le gerer de maniere efficace, un tiers peut participer a la gestion du risque pour le compte de I’organisation. 
Lorsque le risque global du projet est negatif, une strategie de transfert est necessaire ; elle peut impliquer le 
versement d’une prime de risque. Dans le cas d’un risque global du projet tres positif, la responsabilite peut etre 
partagee afin de recolter les avantages associes. La mise en place d’une structure d’entreprise collaborative au 
sein de laquelle I’acheteur et le vendeur partagent le risque global du projet, la creation d’une joint venture ou 
d’une societe a finalite specifique ou encore la sous-traitance d’elements majeurs du projet sont des exemples 
de strategies de transfert et de partage pour le risque global du projet. 
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♦ Attenuer/ameliorer. Ces strategies consistent a changer le niveau du risque global du projet afin d’optimiser 
les chances de realiser les objectifs du projet. La strategie d’attenuation est utilisee lorsque le risque global du 
projet est negatif, et I’amelioration s’applique lorsqu’il est positif. La replanification du projet, le changement du 
perimetre et des limites du projet, la modification de la priorite du projet, le changement dans les allocations des 
ressources et I'ajustement des delais de livraison sont des exemples de strategies d’attenuation ou d’amelioration. 

♦ Accepter. Lorsqu’aucune strategie proactive de reponse au risque n’est possible pour gerer le risque global du 
projet, I’organisation peut decider de poursuivre le projet tel qu’il est actuellement defini, memesi le risque global 
du projet est en dehors des seuils convenus. L’acceptation peut etre active ou passive. La strategie d’acceptation 
active la plus repandue consiste a constituer une reserve pour alea globale pour le projet, incluant le temps, les 
moyens financiers ou les ressources a utiliser si le projet depasse les seuils. L’acceptation passive ne demande 
aucune action proactive hormis la revue periodique du niveau du risque global du projet afin de s’assurer qu’il ne 
change pas de maniere significative. 

11.5.2.8 ANALYSE DES DONNEES 

Plusieurs strategies de reponse au risque peuvent etre prises en consideration. Parmi les techniques d’analyse des 
donnees pouvant etre utilisees pour selectionner la strategie preferee de reponse au risque figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. Une simple comparaison des caracteristiques et des exigences liees aux differentes 
options de reponse au risque peut permettre de decider de la reponse la plus appropriee. 

♦ Analyse cout-benefice. Si I'impact d’un risque individuel du projet peut etre quantifie en termes monetaires, 
la rentabilite des differentes strategies de reponse au risque peut etre determinee a I’aide d’une analyse cout- 
benefice (voir la section 8.1.2.3). Le ratio du (changement du niveau d’impact) divise par le (cout d'execution de 
la reponse) donne la rentabilite de la strategie de reponse, un ratio superieur indiquant une reponse plus efficace. 

11.5.2.9 PRISE DE DECISION 

Parmi les techniques de prise de decision qui peuvent etre utilisees pour selectionner une strategie de reponse 
au risque, figure notamment I’analyse decisionnelle multicritere (decrite a la section 8.1.2.4). Elle peut prendre en 
consideration une ou plusieurs strategies de reponse au risque. Les techniques de prise de decision peuvent permettre 
de prioriser les strategies de reponse au risque. L’analyse decisionnelle multicritere utilise une matrice de decision 
pour fournir une approche systematique afin d'etablir des criteres de decision cles, d’evaluer et de classer les options 
mais aussi de selectionner la meilleure d’entre elles. Les criteres de selection des reponses aux risques incluent, entre 
autres, le cout de la reponse, I’efficacite probable de la reponse a changer la probabilite et/ou I’impact, la disponibilite 
des ressources, les contraintes de temps (urgence, proximite et inactivite), le niveau d’impact si le risque survient, I’effet 
de la reponse sur les risques associes et I'introduction de risques secondaires. Si le choix initial s'avere inefficace, des 
strategies differentes peuvent etre selectionnees ulterieurement au cours du projet. 
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11.5.3 PLANIFIER LES REPONSES AUX RISQUES : DONNEES DE SORTIE 


11.5.3.1 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Les reponses aux risques planifiees peuvent conduire a une demande de 
changement des references de base des couts et de I'echeancier ou d’autres composants du plan de management du 
projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements 
(voir la section 4.6). 

11.5.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion de I’echeancier. II est decrit a la section 6.1.3.1. II inclut les changements apportes au plan de 
gestion des changements, tels que les changements lies au chargement et au nivellement des ressources ou les 
mises a jour de la strategie de I'echeancier. 

♦ Plan de gestion des couts. II est decrit a la section 7.1.3.1. II inclut les changements apportes au plan de gestion 
des couts, tels que les changements en relation avec la comptabilite analytique, le suivi et les rapports ainsi que 
les mises a jour de la strategie du budget et la maniere selon laquelle les reserves pour alea seront utilisees. 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. II integre les changements apportes au plan de 
gestion de la qualite, tels que les changements concernant les approches visant a satisfaire aux exigences, les 
approches de gestion de la qualite ou les processus de controle de la qualite. 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. II inclut les changements apportes au plan de 
gestion des ressources, tels que les changements lies a I’allocation des ressources ainsi que les mises a jour de 
la strategie de gestion des ressources. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. II integre les changements apportes 
au plan de gestion des approvisionnements, tels que les changements dans la decision « make-or-buy» ou le 
type de contrat. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Les changements apportes a la reference 
de base du perimetre sont incorpores a la suite de changements approuves du perimetre qui peuvent decouler 
des reponses aux risques. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. Les changements apportes a la 
reference de base de I’echeancier sont incorpores a la suite de changements approuves des estimations de 
I’echeancier, qui peuvent decouler des reponses aux risques. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les changements apportes a la reference 
de base des couts sont incorpores a la suite de changements approuves des estimations de cout, qui peuvent 
decouler des reponses aux risques. 
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11.5.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Au cours du processus Planifier les reponses aux 
risques, de nouvelles hypotheses peuvent etre formulees, de nouvelles contraintes peuvent etre identifies et les 
hypotheses ou les contraintes existantes peuvent etre passees en revues et changees. Le journal des hypotheses 
doit etre mis a jour afin d’inclure ces nouvelles informations. 

♦ Previsions de couts. Elies sont decrites a la section 7.4.3.2. Les previsions de couts peuvent changer en 
consequence des reponses aux risques planifiees. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est 
mis a jour a I'aide des informations sur les reponses aux risques qui peuvent etre utiles lors des futures phases 
du projet ou de projets ulterieurs. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. Les activites relatives aux reponses aux risques convenues 
peuvent etre ajoutees a I’echeancier du projet. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.2. Une fois les reponses 
confirmees, les ressources necessaires doivent etre affectees a chaque action associee a un plan de reponse au 
risque. Ces ressources incluent un personnel experiment et dument qualifie pour executer I'action approuvee 
(generalement au sein de I’equipe projet), un budget specifique, un delai d’action et toutes les ressources 
techniques necessaires pour mener a bien cette action. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour lorsque des 
reponses aux risques appropriees sont choisies et validees. Les mises a jour du registre des risques comprennent, 
entre autres: 

■ les strategies de reponse validees; 

■ les actions specifiques pour mettre en oeuvre la strategie de reponse choisie; 

■ les conditions de declenchement, les symptomes et les signaux divertissement concernant I’occurrence 
des risques; 

■ le budget et les activites de I’echeancier necessaires pour executer les reponses choisies; 

■ les plans de contingence et les declencheurs de risque qui entrainent leur execution ; 

■ les plans de repli a mettre en oeuvre lorsqu’un risque s’est produit et que la reponse initiale s’est averee 
inadequate; 

■ les risques residuels qui subsistent une fois les reponses prevues executees aussi bien que les risques qui 
ont ete deliberement acceptes ; 

■ les risques secondaires qui surviennent en consequence directe de I'execution d’une reponse a un risque. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques peut etre mis a jour afin de 
presenter les reponses validees a I’exposition au risque global du projet, aux risques a priorite elevee ainsi qu'aux 
changements prevus qui peuvent etre attendus a la suite de I’execution de ces reponses. 
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11.6 EXECUTER LES REPONSES AUX RISQUES 


Executer les reponses aux risques est le processus qui consiste a mettre en oeuvre les plans de reponse aux risques. 
L'interet principal de ce processus est qu’il garantit que les plans de reponse aux risques sont executes comme prevu 
afin de gerer I'exposition au risque global du projet, de minimiser les menaces individuelles du projet et de renforcer les 
opportunity individuelles du projet. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, 
les techniques et les donnees de sortie de ce processus sont presentes a la figure 11-18. La figure 11-19 presente le 
diagramme de flux de donnees du processus. 


Executer les reponses aux risques 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion des risques 
.2 Documents du projet 

• Registre des retours 
d'experience 

• Registre des risques 

• Rapport sur les risques 
.3 Actifs organisationnels 

V___/ 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Competences 

interpersonnelles et d'equipe 
• Influence 

.3 Systeme d'information 
de gestion du projet (Project 
Management Information 
System, PMIS) 

V___/ 


Donnees de sortie 


.1 Demandes de changement 
.2 Mises a jour des documents 
du projet 

• Journal des points a traiter 

• Registre des retours 
d'experience 

• Affectations des membres 
de 1'equipe projet 

• Registre des risques 

• Rapport sur les risques 

V ___ 


Figure 11-18. Executer les reponses aux risques : donnees d’entree, outils, techniques et donnees de sortie 



• Actifs organisationnels 


Registre des risques 
Rapport sur les risques 


Figure 11-19. Executer les reponses aux risques: diagramme de flux de donnees 
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II convient de porter attention au processus Executer les reponses aux risques afin que les reponses aux risques 
validees soient veritablement executees. Les equipes projet rencontrent souvent le meme probleme en matiere de 
gestion des risques du projet: elles s’efforcent d’identifier et d’analyser les risques mais aussi d’elaborer des reponses a 
ces risques. Ensuite, ces reponses sont validees et consignees dans le registre des risques et le rapport sur les risques, 
mais aucune action n’est prise pour gerer le risque. 

L’exposition au risque global du projet et aux menaces et opportunity individuelles pourra etre geree de maniere 
proactive uniquement si les charges de risque fournissent le niveau d’effort requis pour executer les reponses convenues. 


11.6.1 EXECUTER LES REPONSES AUX RISQUES : DONNEES D’ENTREE 

11.6.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, 
le plan de gestion des risques. Decrit a la section 11.1.3.1, le plan de gestion des risques enumere les roles et les 
responsabilites des membres de I'equipe projet et des autres parties prenantes en matiere de gestion des risques. 
Ces informations sont utilisees au moment de designer des responsables pour les reponses aux risques. Le plan de 
gestion des risques definit egalement le niveau de detail de la methodologie de gestion des risques pour le projet. 
Enfin, il indique les seuils de risque pour le projet fondes sur I’appetence au risque des principales parties prenantes, 
qui definissent I’objectif acceptable que I'execution des reponses aux risques doit atteindre. 

11.6.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du projet, 
relatifs a I’execution des reponses aux risques, peuvent etre appliques aux phases ulterieures afin d’ameliorer 
I’efficacite de ce processus. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques consigne les reponses aux 
risques validees pour chaque risque individuel et les responsables designes pour chaque plan de reponse. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques inclut une evaluation de 
I’exposition actuelle au risque global du projet et la strategie de reponse au risque approuvee. II decrit egalement 
les risques individuels majeurs et les reponses planifiees. 

11.6.1.3 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent influencer le processus Executer les reponses aux risques figure, 
entre autres, I'archive des retours d'experience de projets similaires acheves qui indiquent I’efficacite de reponses aux 
risques specifiques. 
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11.6.2 EXECUTER LES REPONSES AUX RISQUES : OUTILS ET TECHNIQUES 


11.6.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a des experts pour valider ou modifier les reponses aux 
risques, si necessaire, et decider de leur execution de la maniere la plus efficace. 

11.6.2.2 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure notamment 
I’influence. Certaines actions de reponse au risque peuvent etre conduites sous la direction de personnes exterieures 
a I’equipe projet immediate ou qui ont d’autres contraintes divergentes. II peut s'averer necessaire pour le chef de 
projet ou la personne chargee de faciliter le processus de risque d’exercer son influence (voir la section 9.5.2.1) pour 
encourager les charges de risque designes a prendre les mesures necessaires, le cas echeant. 

11.6.2.3 SYSTEME D’INFORMATION DE MANAGEMENT DU PROJET (PROJECT MANAGEMENT INFORMATION 
SYSTEM, PMIS) 

II est decrit a la section 4.3.2.2. Les systemes d’information de gestion du projet peuvent inclure I'echeancier, les 
ressources et le logiciel de gestion des couts afin de garantir que les plans de reponse au risque convenus et leurs 
activites associees sont integres au projet avec les autres activites du projet. 


11.6.3 EXECUTER LES REPONSES AUX RISQUES : DONNEES DE SORTIE 
11.6.3.1 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. L’execution des reponses aux risques peut conduire a une demande de 
changement des references de base des couts et de I’echeancier ou d’autres composants du plan de management du 
projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements 
(voir la section 4.6). 
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11.6.3.2 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Lorsque des points a traiter sont identifies dans 
le cadre du processus Executer les reponses aux risques, ils sont consignes dans le journal des points a traiter. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour a I’aide des informations sur les difficulty rencontrees lors de I’execution des reponses aux risques, sur 
les moyens pour les eviter et sur les approches qui ont permis d’executer les reponses aux risques. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.2. Une fois les reponses 
aux risques confirmees, les ressources necessaires doivent etre affectees a chaque action associee a un plan de 
reponse au risque. Ces ressources incluent un personnel experiment et dument qualifie pour executer Taction 
approuvee, un budget specifique, un delai d’action et toutes les ressources techniques necessaires pour mener 
a bien cette action. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques peut etre mis a jour afin de 
refleter tout changement dans les reponses aux risques prealablement validees pour les risques individuels, qui 
est ulterieurement apporte a la suite du processus Executer les reponses aux risques. 

♦ Rapport sur les risques. II est decrit a la section 11 .2.3.2. Le rapport sur les risques peut etre mis a jour afin de 
refleter tout changement aux reponses validees a I’exposition au risque global du projet, qui est ulterieurement 
apporte a la suite du processus Executer les reponses aux risques. 


452 


Premiere partie - Guide 



11.7 MAITRISER LES RISQUES 


MaTtriser les risques est le processus qui consiste a suivre la mise en oeuvre des plans valides de reponse aux 
risques, a faire le suivi des risques identifies, a identifier de nouveaux risques, a les analyser et a evaluer I’efficacite du 
processus de gestion des risques tout au long du projet. L'interet principal de ce processus est qu’il permet de fonder 
les decisions du projet sur les informations actuelles concernant I’exposition au risque global du projet et les risques 
individuels du projet. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques 
et les donnees de sortie de ce processus sont presentes a la figure 11 -20. La figure 11 -21 presente le diagramme de 
flux de donnees du processus. 




.1 Elaborer le plan 

de management du projet 
• Plan de gestion des risques 


.1 Analyse des donnees 


• Analyse de la performance 
technique 


.1 Information sur 

la performance d'execution 


.2 Demandes de changement 


.2 Documents du projet 

• Journal des points a traiter 

• Registre des retours 


• Analyse de la reserve 
.2 Audits 
.3 Reunions 


.3 Mises a jour du plan 
de management du projet 
• Tout composant 


d'experience 

• Registre des risques 

• Rapport sur les risques 


V 


.4 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des retours 


.3 Donnees de performance 
d'execution 


.4 Rapports sur la performance 
d'execution 


d'experience 

• Registre des risques 

• Rapport sur les risques 


.5 Mises a jour des actifs 
organisationnels 


V. 


Figure 11-20. Maitriser les risques : donnees d’entree, outils, techniques et donnees de sortie 
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Figure 11-21. Maitriser les risques: diagramme de flux de donnees 


Afin de garantir que I’equipe projet et les principales parties prenantes connaissent le niveau d’exposition aux risques, 
le travail du projet doit etre suivi en permanence, notamment les risques individuels nouveaux, changeants et obsoletes 
mais aussi les changements du niveau de risque global du projet, en executant le processus Maitriser les risques. Ce 
processus utilise les informations de performance generees au cours de I’execution du projet afin de determiner si: 

♦ les reponses aux risques executees sont efficaces ; 

♦ le niveau du risque global du projet a change ; 

♦ le statut des risques individuels identifies du projet a change ; 

♦ de nouveaux risques individuels se presented; 

♦ I’approche de gestion des risques est toujours appropriee ; 

♦ les hypotheses du projet sont toujours valables ; 

♦ les politiques et les procedures de gestion des risques sont respectees ; 

♦ les reserves pour alea concernant le cout ou I’echeancier doivent etre modifiees ; 

♦ la strategic du projet est toujours valable. 
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11.7.1 MAITRISER LES RISQUES : DONNEES D’ENTREE 


11.7.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Parmi les composants du plan de management du projet figure, entre autres, le 
plan de gestion des risques decrit a la section 11.3.1.1. Le plan de gestion des risques indique comment et quand 
les risques doivent etre passes en revue, quelles politiques et procedures il convient de respecter, les roles et les 
responsabilites dans le processus de maTtrise mais aussi les formats des rapports. 

11.7.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter permet de determiner 
si des points a traiter ouverts ont ete mis a jour et necessitent de mettre a jour le registre des risques. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience lies au risque 
collectes au debut du projet peuvent etre appliques aux phases ulterieures. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques comprend des donnees d’entree 
cles, notamment les risques individuels du projet identifies, les charges de risque, les reponses aux risques 
convenues et les actions d'execution specifiques. II peut egalementfournir d'autres details, tels que les actions 
de controle destinees a evaluer I’efficacite des plans de reponse, les symptomes et les signaux divertissement 
du risque, les risques secondaires et residuels mais aussi une liste de veille des risques a faible priorite. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Le rapport sur les risques inclut une evaluation de 
I’exposition actuelle au risque global du projet et la strategie de reponse au risque approuvee. II decrit egalement 
les risques individuels majeurs, les reponses prevues et les charges de risque. 
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11.7.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent des informations sur 
I'etat du projet, notamment les reponses aux risques executees, les risques survenus, les risques actifs et ceux qui ont 
ete clos. 

11.7.1.4 RAPPORTS SUR LA PERFORMANCE D’EXECUTION 

Ms sont decrits a la section 4.5.3.1. Les rapports sur la performance d’execution fournissent des informations provenant 
des mesures de performance qui peuvent etre analysees pour donner des informations sur la performance d’execution, 
incluant I'analyse des ecarts, les donnees sur la valeur acquise et les donnees de prevision. Ces informations peuvent 
etre utiles pour suivre les risques lies a la performance. 


11.7.2 MAITRISER LES RISQUES : OUTILS ET TECHNIQUES 

11.7.2.1 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse de la performance technique. L’analyse de la performance technique compare les realisations 
techniques constatees au cours de I’execution du projet avec I’echeancier des realisations techniques prevues. 
Elle exige la definition de mesures objectives et quantifiables de la performance technique, qui peuvent etre 
utilisees pour comparer les resultats reels aux objectifs. Ces mesures de la performance technique peuvent 
inclure le poids, les temps de transaction, le nombre de pieces defectueuses produites et la capacity de stockage. 
Un ecart peut indiquer I’impact potentiel de menaces ou d’opportunites. 

♦ Analyse de la reserve. Elle est decrite a la section 7.2.2.6. Pendant I’execution du projet, certains risques 
individuels peuvent se produire, avec des impacts positifs ou negatifs sur le budget ou sur les reserves pour alea 
de I'echeancier. L’analyse de la reserve compare, a tout moment, le montant restant des reserves pour alea au 
niveau du risque actuel, afin de determiner si la reserve restante est adequate. Elle peut etre communiquee au 
moyen de differentes representations graphiques, y compris un diagramme du travail restant («burndown chart»). 

11.7.2.2 AUDITS 

Ms sont decrits a la section 8.2.2.5. Les audits de risques sont un type d’audit utilise pour evaluer I’efficacite des 
processus de gestion des risques. Le chef de projet est charge de s’assurer que les audits de risques sont effectues a 
frequence appropriee, comme defini dans le plan de gestion des risques du projet. Des audits de risque peuvent etre 
inclus a des revues periodiques de projet ou faire partie des revues des risques. Autre possibility, I’equipe peut choisir 
d’organiser des reunions d’audit de risques separees. Le format de I’audit de risques et ses objectifs doivent etre 
clairement definis avant que I’audit ne soit conduit. 
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11.7.2.3 REUNIONS 

Parmi les reunions pouvant etre utilisees au cours de ce processus figurent notamment les revues des risques. Ces 
dernieres sont regulierement planifiees et doivent examiner et documenter I’efficacite des reponses aux risques dans 
la gestion du risque global et des risques individuels identifies du projet. Les revues des risques peuvent egalement 
permettre d'identifier de nouveaux risques individuels (y compris les risques secondaires qui decoulent des reponses 
aux risques validees), de reevaluer les risques actuels, de clore les risques obsoletes et les points a traiter resultant des 
risques survenus mais aussi d'identifier les retours d'experience eventuels a des fins d’application au cours des phases 
du projet actuel ou de projets similaires a I’avenir. La revue des risques peut etre menee dans le cadre d’une reunion 
periodique sur I’etat du projet ou d’une reunion dediee a la revue des risques, comme indique dans le plan de gestion 
des risques. 


11.7.3 MAITRISER LES RISQUES : DONNEES DE SORTIE 

11.7.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d'execution inclut des donnees sur la fagon 
dont la gestion des risques du projet est appliquee en comparant, d’une part, les risques individuels qui sont survenus 
et, d’autre part, la fagon dont il etait prevu qu’ils surviennent. Ces informations indiquent I’efficacite des processus de 
planification et d’execution des reponses. 

11.7.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Le processus MaTtriser les risques peut conduire a une demande de 
changement des references de base des couts et de I’echeancier ou d’autres composants du plan de management du 
projet. Les demandes de changement sont passees en revue et traitees par le processus MaTtriser les changements 
(voir la section 4.6). 

Elies peuvent inclure les actions preventives et correctives recommandees destinees a gerer le niveau actuel du 
risque global du projet ou a gerer les risques individuels du projet. 

11.7.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. II peut concerner tout composant du plan de 
management du projet. 
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11.7.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Au cours du processus MaTtriser les risques, de 
nouvelles hypotheses peuvent etre formulees, de nouvelles contraintes peuvent etre identifies et les hypotheses 
ou les contraintes existantes peuvent etre passees en revue et changees. Le journal des hypotheses est mis a 
jourafin d’inclure ces nouvelles informations. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Lorsque des points a traiter sont identifies dans le 
cadre du processus MaTtriser les risques, ils sont consignes dans le journal des points a traiter. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour afin d’inclure tout retour d’experience lie au risque au cours des revues des risques et de pouvoir I’utiliser 
lors de phases ulterieures ou de futurs projets. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques est mis a jour afin d'inclure les 
informations sur les risques individuels du projet generes au cours du processus MaTtriser les risques. Cette mise 
a jour peut consister a ajouter de nouveaux risques, mettre a jour des risques obsoletes ou des risques qui se 
sont produits, mettre a jour les reponses aux risques ou autres. 

♦ Rapport sur les risques. II est decrit a la section 11.2.3.2. Au fur et a mesure que de nouvelles informations 
sont disponibles au cours du processus MaTtriser les risques, le rapport sur les risques est mis a jour afin de 
refleter le statut actuel des principaux risques individuels du projet et le niveau actuel du risque global du projet. 
Le rapport sur les risques peut egalement detainer les risques individuels majeurs, les reponses et les charges de 
risque approuves ainsi que des conclusions et des recommandations. II peut egalement inclure les conclusions 
des audits de risques sur I’efficacite du processus de gestion des risques. 

11.7.3.5 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui sont mis a jour suite au processus MaTtriser les risques, on peut citer: 

♦ les modeles de plan de gestion des risques, le registre des risques, le rapport sur les risques ; 

♦ I’organigramme des risques. 
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GESTION DES APPROVISIONNEMENTS DU PROJET 

La gestion des approvisionnements du projet comprend les processus d’achat ou d’acquisition des produits, des 
services ou des resultats necessaires et externes a I'equipe projet. Sont egalement compris les processus de gestion et 
de martrise necessaires pour elaborer et gerer des accords, comme les contrats, les bons de commande, les protocoles 
d’accord (MOA) ou les accords de niveau de service internes (SLA). Les personnels habilites a acheter les biens et/ou 
services requis pour le projet peuvent etre les membres de I’equipe projet, de la direction ou du service des achats de 
I'organisation, selon les cas. 

Les processus de gestion des approvisionnements du projet sont les suivants: 

12.1 Planifier la gestion des approvisionnements —Ce processus consiste a documenter les decisions 
d’approvisionnement du projet, a specifier les principes et a identifier les vendeurs potentiels. 

12.2 Proceder aux approvisionnements —Ce processus consiste a obtenir les reponses de vendeurs, a selectionner 
un vendeur et a attribuer un contrat. 

12.3 MaTtriser les approvisionnements —Ce processus consiste a gerer les relations fournisseurs, a suivre la 
performance, a apporter les changements et corrections appropriees, le cas echeant, et a conclure des contrats. 

Les processus d'approvisionnement sont presentes comme des processus distincts aux interfaces clairement definies. 
Dans la pratique, ils peuvent etre complexes et interagir entre eux mais aussi avec les processus d'autres domaines de 
connaissances de manieres qui ne peuvent pas etre completement detaillees dans le Guide PMBOK®. Les processus 
decrits dans cette section partent du principe que les biens ou les services proviennent de sources exterieures au projet. 

La figure 12-1 donne une vue d'ensemble des processus de gestion des approvisionnements du projet. Les processus 
de gestion des approvisionnements du projet sont presentes comme des processus distincts aux interfaces clairement 
definies tandis que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre 
completement detaillees dans le Guide PMBOK®. 
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12.3 Maitriser 
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Figure 12-1. Vue d’ensemble de la gestion des approvisionnements du projet 


PRINCIPAUX CONCEPTS DE LA GESTION DES APPROVISIONNEMENTS DU PROJET 

Plus que tout autre processus du management de projet, le processus d’approvisionnement est davantage lie a 
des sanctions et obligations juridiques importantes. Le chef de projet ne doit pas forcement etre un expert des lois 
et des regimentations en matiere de gestion des approvisionnements. En revanche, il doit connaTtre suffisamment 
le processus d’approvisionnement pour prendre des decisions intelligentes concernant les contrats et les relations 
contractuelles. En general, le chef de projet n’est pas autorise a signer des accords juridiques qui lient I’organisation. 
Cette tache est reservee aux personnes possedant la capacite necessaire. 

Les processus de gestion des approvisionnements du projet prevoient des accords qui decrivent la relation entre deux 
parties, a savoir un acheteur et un vendeur. II peut s’agir d’un simple achat d’une quantite definie d’heures de travail a 
un taux horaire specifie ou d’accords plus complexes, comme des contrats de construction internationaux pluriannuels. 
Le principe contractuel et le contrat doivent refleter la simplicite ou la complexite des livrables ou du moins I’effort 
necessaire. Ms doivent etre rediges conformementaux lois locales, nationales et internationales relatives aux contrats. 
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Un contrat doit enoncer clairement les livrables et les resultats attendus, y compris tout transfer! de connaissances 
entre le vendeur et I'acheteur. Seules les dispositions du contrat sont applicables sur le plan juridique. Les chefs de 
projet qui agissent au niveau international doivent tenir compte des effets de la culture et de la legislation locale sur les 
contrats et leur applicability, meme si le contrat est bien redige. 

Un contrat d’achat comprend des conditions generates, et peut comporter d’autres particularity de I’acheteur, pour 
definir ce que le vendeur sera appele a executer ou a fournir. II est du ressort de I’equipe de management de projet de 
s'assurer que tous les approvisionnements satisfont les besoins specifiques du projet, tout en collaborant avec le bureau 
des achats afin de garantir le respect des politiques de I'organisation en matiere d’approvisionnements. En fonction du 
champ d’application, un accord peut egalement etre un contrat, un accord de niveau de service (SLA), une entente, un 
protocole d’accord (MOA) ou un bon de commande. 

La plupart des organisations documentent des politiques et des procedures qui definissent specifiquement les regies 
d’approvisionnement et qui identifient la personne investie de la capacity pour signer et pour gerer de tels accords pour 
le compte de I'organisation. Bien que les organisations du monde entier utilisent des noms differents pour designer 
les services ou les divisions en charge de I'approvisionnement (achats, passation de marches, approvisionnement ou 
acquisitions), leurs responsabilites sont probablement similaires. 

Bien que tous les documents d’un projet soient susceptibles d’etre soumis a une certaine forme de revue et 
d’approbation, le caractere juridiquement contraignant d’un contrat signifie normalement qu’il sera soumis a un 
processus d'approbation plus elabore auquel participe souvent le service juridique. Dans tous les cas, I’intention 
premiere du processus de revue et d’approbation est de s’assurer que le contrat decrit convenablement les produits, 
les services ou les resultats que le vendeur convient de fournir, tout en etant conforme aux lois et aux reglementations 
sur les approvisionnements. Ces sections sont souvent des annexes distinctes qui permettent I’utilisation des termes 
juridiques standardises du contrat. 

Un projet complexe peut impliquer la gestion simultanee ou sequentielle de plusieurs contrats. Dans ces cas, le cycle 
de vie de chaque contrat peut commencer et s'achever au cours de n’importe quelle phase du cycle de vie du projet. 
La relation entre acheteur et vendeur peut exister a differents niveaux dans un projet donne, et entre des organisations 
internes et externes a I'organisation acheteuse. 

En fonction du champ d’application, le vendeur peut etre appele entrepreneur, vendeur, prestataire de services ou 
fournisseur. L’acheteur peut etre le proprietaire du produit final, un sous-traitant, I’organisation acheteuse, un demandeur 
de services ou I’acquereur. Au cours du cycle de vie du contrat, le vendeur peut etre considere tout d’abord comme 
soumissionnaire, puis comme source selectionnee, et finalement comme vendeur ou fournisseur sous contrat. 
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Le soumissionnaire retenu peut gerer le travail comme un projet. Dans ce cas: 

♦ L'acheteur devient le client des sous-traitants, des fournisseurs et des prestataires de services et, par la meme, 
une partie prenante cle du projet pour le vendeur. 

♦ L’equipe de management de projet du vendeur peut etre concernee par tous les processus requis pour executer 
le travail ou fournir les services. 

♦ Les conditions generates du contrat et I’enonce des travaux d’approvisionnement deviennent des donnees 
d’entree cles pour de nombreux processus de management du vendeur. Le contrat peut contenir les donnees 
d’entree (par exemple, les principaux livrables, les jalons cles, les objectifs de couts) ou limiter les options de 
I’equipe projet. Par exemple, dans le cadre des projets d’integration informatique, I'accord de l’acheteur est 
souvent necessaire pour les decisions concernant I’utilisation des ressources humaines. L'enonce des travaux 
d’approvisionnement peut egalement etre appele enonce technique des travaux. 

♦ Le vendeur peut devenir un acheteur de produits, de services et de materiaux de niveau du WBS inferieur aupres 
de sous-traitants et de fournisseurs. 

Cette section part du principe que l’acheteur d’un article pour le projet est affecte a I’equipe projet et/ou fait partie 
de I'organisation dans son ensemble. Le vendeur est suppose livrer des services et/ou des materiaux au projet. II est 
generalement exterieur a I'organisation realisatrice. Pour certains projets, le role du vendeur peut etre assume par un 
groupe ou une fonction qui fait partie de I’organisation realisatrice mais est externe au projet. Pour les projets plus 
grands et complexes, le vendeur peut faire partie d’une equipe projet integree une fois le contrat conclu. 

Pour les organisations plus petites ou les startups ainsi que pour les societes qui ne disposent pas d’un service 
achats, d’attribution de marches ou d’approvisionnement, le chef de projet peut assumer la fonction de responsable 
des achats afin de negocier et signer des contrats directement (achats decentralises). Pour les organisations deja bien 
etablies, les fonctions d’approvisionnement et de passation de marches actuelles seront confiees a un service distinct 
charge specialement des achats, de la negociation et de la signature des contrats (achats centralises). 

Dans le cadre de contrats internationaux, les competences juridiques en vertu desquelles les contrats seront geres 
sont clairement enoncees dans le contrat. Le plus souvent, le vendeur est un entrepreneur externe lie par une relation 
contractuelle officielle. 
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TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES APPROVISIONNEMENTS 


II existe un certain nombre de grandes tendances associees aux outils logiciels, aux risques, a la logistique et 
aux technologies dans differents secteurs qui peuvent influencer le taux de reussite des projets. Les tendances et 
pratiques emergentes en gestion des approvisionnements du projet comprennent notamment les elements suivants: 

♦ Perfectionnement des outils. Des ameliorations significatives ont ete apportees au developpement 
d’outils pour gerer I'approvisionnement et Implication des phases d’un projet. Grace aux outils en ligne 
lies a I'approvisionnement, les acheteurs beneficient desormais d’un seul support pour annoncer les 
approvisionnements. De plus, ils constituent pour les vendeurs une source unique ou trouver les documents 
d’approvisionnements et les renseigner directement en ligne. Dans le secteur de la construction, de I'ingenierie 
et de I’infrastructure, I’utilisation croissante du modele d’information de construction (BIM) au niveau des outils 
logiciels permettrait de realiser d'importantes economies de temps et financiers sur les projets. Cette approche 
peut limiter considerablement les reclamations liees a la construction, reduisant ainsi les couts et accelerant 
I’echeancier. Les principaux gouvernements et entreprises du monde entier commencent a imposer I’utilisation 
de la maquette numerique du batiment dans le cadre de projets importants. 

♦ Gestion plus avancee des risques. La tendance croissance en matiere de gestion des risques consiste a rediger 
des contrats qui conferent les risques specifiques aux entites les mieux a meme de les gerer. Aucun entrepreneur 
n’est en mesure de gerer tous les eventuels risques majeurs d’un projet. L’acheteur devra accepter les risques 
sur lesquels les entrepreneurs n'ont pas de prise, comme revolution des politiques internes de I'entreprise 
acheteuse, le changement des exigences reglementaires et les autres risques exterieurs au projet. Les contrats 
peuvent preciser que la gestion des risques fait partie du contrat. 

♦ Evolution des processus d’attribution de contrat. Depuis quelques annees, les megaprojets ont explose, 
notamment dans les domaines des projets d'ingenierie et de developpement d’infrastructures. Les projets a 
plusieurs milliards de dollars sont desormais monnaie courante. La plupart prevoient des contrats internationaux 
avec plusieurs entrepreneurs de pays differents. De ce fait, ils sont plus risques que les projets faisant appel 
uniquement a des entrepreneurs locaux. L'entrepreneur travaille de plus en plus en etroite collaboration avec 
le client lors du processus d’approvisionnement afin de profiter de reductions grace a des achats en quantites 
importantes ou a d'autres considerations speciales. Pour ces projets, I’utilisation de modeles de contrat type 
reconnus a I’echelle internationale se generalise afin de reduire les problemes et les reclamations au cours 
de I'execution. 
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♦ Gestion de la logistique et de la chatne d’approvisionnement. Etant donne que de nombreux projets 
d'ingenierie, de construction etd’infrastructure importants sontconfies a differents entrepreneurs internationaux, 
la gestion des flux de materiaux devient indispensable a leur reussite. Pour les articles a long delai de livraison, 
leurs fabrication et transport jusqu'au site du projet deviennent des facteurs cles pour I’echeancier. Dans le 
secteur informatique, un article a long delai de livraison peut necessiter une commande 2 ou 3 mois a I'avance. 
Pour les projets de construction complexes, les postes a long delai de livraison peuvent necessiter une commande 
1 ou 2 ans a I'avance, voire plus. Pour ces projets, les postes a long delai de livraison peuvent etre achetes a 
I’avance par rapport a d’autres contrats d'approvisionnement afin de respecter la date de fin prevue du projet. II 
est possible de commencer a conclure des marches pour ces materiaux, fournitures ou equipements a long delai 
de livraison avant la fin de la conception finale du produit fini, en fonction des exigences connues et identifies 
dans la conception de haut niveau. La gestion de la chame d'approvisionnement est un domaine auquel 
Pequipe projet de I’entrepreneur accorde plus d’importance. Si les principales sources d’approvisionnement 
sont identifies au debut du projet, il en va generalement de meme pour is sources secondaires. Bon nombre 
de pays demandent aux entrepreneurs internationaux d’acheter un certain pourcentage minimum de materiaux 
et de fournitures aupres des fournisseurs locaux. 

♦ Technologies et relations avec les parties prenantes. Les projets finances par le secteur public sont de plus 
en plus surveilis. La tendance dans les projets de construction commerciale et d’infrastructures est I’utilisation 
de technologies, comme is webcams, afin d’ameliorer is communications et is relations avec is parties 
prenantes. Lors de la construction, une ou plusieurs webcams sont instalies sur le site, avec des mises a jour 
regulieres sur un site Internet public. Toutes is parties prenantes peuvent constater I’avancement du projet 
sur Internet. Les donnees video peuvent egalement etre stockees et permettre ainsi une analyse en cas de 
reclamation. Lors de certains projets, I’utilisation de webcams s'est montree capable de minimiser is differends 
lies aux travaux de construction sur le site. En effet, is webcams permettent d’enregistrer is evenements et 
ainsi d’eliminer toute mesentente a propos des faits. 

♦ Gontrat a I’essai. L'environnement de I’organisation ne convient pas a tous is vendeurs. C’est pourquoi, pour 
certains projets, des vendeurs candidats sont engages afin de realiser is premiers livrables et produits, puis 
remuneres avant d’etre pleinement engages pour une plus grande partie du perimetre du projet. Cette pratique 
permet d’acceirer la dynamique en permettant a I’acheteur d'evaluer ses partenaires potentiels tout en faisant 
avancer is travaux du projet. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 

Chaque projet etant unique, le chef de projet devra adapter I’application de chacun des processus de gestion des 
approvisionnements du projet. Parmi les considerations relatives a I’adaptation, on peut citer les elements suivants: 

♦ Complexity de I’approvisionnement. S’agit-il d’un approvisionnement principal ou de plusieurs 
approvisionnements realises a differents moments aupres de divers vendeurs qui s’ajoutent a la complexity des 
approvisionnements ? 

♦ Emplacement physique. Les acheteurset les vendeurssetrouvent-ilsaumemeendroit?Sont-ilsraisonnablement 
proches ? Se situent-ils dans differents fuseaux horaires, pays ou continents ? 

♦ Environnement de gouvernance et reglementaire. Les lois et regimentations locales concernant les activites 
d’approvisionnement sont-elles integrees aux politiques d’approvisionnement de I’organisation ? Dans quelle 
mesure cela influence-t-il les exigences en matiere de verification des contrats ? 

♦ Disponibilite des entrepreneurs. Des entrepreneurs sont-ils disponibles et capables de realiser le travail ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Dans les environnements agiles, il est possible de faire appel a certains vendeurs pour etoffer I’equipe. Cette relation 
de travail fondee sur la collaboration peut deboucher sur un modele d’approvisionnement a risques partages ou vendeur 
et acheteur se repartissent les risques et les gains associes a un projet. 

Les projets de plus grande envergure peuvent utiliser une approche adaptative pour certains livrables et une approche 
plus stable pour d’autres. Dans ce cas, il est possible d’avoir recours a un accord-cadre, tel qu’un accord-cadre de 
services, pour I’engagement global. Les adaptations aux livrables figurent dans une annexe ou un supplement. Ainsi, les 
changements peuvent etre apportes au perimetre adaptatif sans affecter le contrat. 
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12.1 PLANIFIER LA GESTION DES APPROVISIONNEMENTS 


Planifier la gestion des approvisionnements est le processus qui consiste a documenter les decisions 
d’approvisionnement du projet, a specifier les principes et a identifier les fournisseurs potentiels. L’interet principal 
de ce processus est qu’il permet de decider d’acquerir ou non des biens et des services a I’exterieur du projet et, le 
cas echeant, ce qu’il faut acquerir, comment et quand. L'approvisionnement en biens et services peut se faire aupres 
d’autres parties de I'organisation realisatrice ou aupres de sources externes. Ce processus est execute une fois ou a des 
points predefinis dans le cadre du projet. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce 
processus sont presentes a la figure 12-2. La figure 12-3 represente le diagramme de flux de donnees de ce processus. 


Planifier la gestion des approvisionnements 


Donnees d’entree 


.1 Elaborer la charte du projet 

.2 Documents business 

• Business case 

• Plan de gestion 
des benefices 

.3 Elaborer le plan 

de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion de la qualite 

• Plan de gestion 
des ressources 

• Reference de base 
du perimetre 

.4 Documents du projet 

• Liste des jalons 

• Affectations des membres 
de I’equipe projet 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

• Besoins en ressources 

• Registre des risques 

• Registre des parties 
prenantes 

.5 Facteurs environnementaux 

de I'organisation 

.6 Actifs organisationnels 

v___y 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Collecte des donnees 

• Etude de marche 

.3 Analyse des donnees 

• Analyse « make-or-buy » 

.4 Analyse de la selection 

des sources 
.5 Reunions 

v_y 


Donnees de sortie 


.1 Plan de gestion 

des approvisionnements 
.2 Strategie 

d'approvisionnement 
.3 Documents d’appel d'offres 
.4 Enonce des travaux 
d'approvisionnement 
.5 Criteres de selection 
des sources 

.6 Decisions « make-or-buy » 

.7 Estimations independantes 
des couts 

.8 Demandes de changement 
.9 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 

• Liste des jalons 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

• Registre des risques 

• Registre des parties 
prenantes 

.10 Mises a jour des actifs 
organisationnels 

v_y 


Figure 12-2. Planifier la gestion des approvisionnements : donnees d’entree, outils, techniques et donnees de sortie 
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• Business case 
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du projet 


Documents du projet 

• Liste des jalons 

• Affectations des membres 
de I’equipe projet 

• Documentation des exigences 

• Matrice de tragabilite des exigences 

• Besoins en ressources 

• Registre des risques 

• Registre des parties prenantes 


Entreprise/ 

Organisation 


d’approvisionnement 

* Documents d’appel d’offres 

* Decisions« make-or-buy» 

* Estimations independantes des couts 


12.1 
Planifier 
la gestion des 
approvisionnements 


* Demandes 
de changement 


► Criteres de selection 
des sources 


4.6 

Effectuer 
la gestion integree 
des changements 


Documents 
du projet 


Mises a jour des documents du projet 

• Registre des retours d’experience 

• Liste des jalons 

• Documentation des exigences 

• Matrice de tragabilite des exigences 

• Registre des risques 

• Registre des parties prenantes 


* Mises a jour des actifs 
organisationnels 


Entreprise/ 

Organisation 


• Facteurs environnementaux 
de (’organisation 

• Actifs organisationnels 


Figure 12-3. Diagramme de flux de donnees du processus Planifier la gestion des approvisionnements 
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II convient de definir les roles et responsabilites lies a I’approvisionnement au debut du processus Planifier la 
gestion des approvisionnements. Le chef de projet doit s’assurer que I’equipe projet possede des competences en 
approvisionnement au niveau requis pour le projet. Parmi les participants au processus d’approvisionnement, on 
peut compter les personnels des services des achats ou de I’approvisionnement ainsi que du service juridique de 
I'organisation acheteuse. Ces responsabilites doivent etre consignees dans le plan de gestion des approvisionnements. 

Les mesures types a prendre pourraient etre les suivantes : 

♦ Preparer I’enonce des travaux d’approvisionnement ou le cahier des charges. 

♦ Preparer une estimation de couts generate afin de determiner le budget. 

♦ Annoncer cette opportunity. 

♦ Identifier une liste de vendeurs qualifies preselectionnes. 

♦ Preparer et delivrer les documents d'appel d’offres. 

♦ Preparer et soumettre les propositions des vendeurs. 

♦ Effectuer une evaluation technique des propositions, y compris revaluation de la qualite. 

♦ Realiser une evaluation des couts des propositions. 

♦ Preparer revaluation combinee des couts et de la qualite finale afin de choisir la proposition selectionnee. 

♦ Finaliser les negociations et signer le contrat entre I'acheteur et le vendeur. 

Les exigences de I'echeancier du projet peuvent avoir une influence significative sur la strategie au cours du 
processus Planifier la gestion des approvisionnements. Les decisions prises dans Pelaboration du plan de gestion des 
approvisionnements peuvent egalement influencer I’echeancier du projet. Elies sont integrees aux processus Elaborer 
I’echeancier et Estimer les ressources necessaires aux activites, ainsi qu’aux decisions« make-or-buy». 


12.1.1 PLANIFIER LA GESTION DES APPROVISIONNEMENTS : DONNEES D’ENTREE 

12.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet inclut les objectifs, la description du projet, un recapitulate des 
jalons et les ressources financieres preapprouvees. 
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12.1.1.2 DOCUMENTS BUSINESS 


Ms sont decrits a la section 1.2.6. Les documents business incluent les elements suivants : 

♦ Business case. La strategie d’approvisionnement et le business case doivent etre alignes afin de garantir la 
validite de ce dernier. 

♦ Plan de gestion des benefices. Le plan de gestion des benefices indique le moment ou les benefices precis du 
projet seront disponibles, ce qui definit les dates d’approvisionnement et les termes du contrat. 

12.1.1.3 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre decrit comment 
les entrepreneurs gereront le perimetre de travail lors de la phase d’execution du projet. 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. Le plan de gestion de la qualite contient les codes 
et standards industriels applicables. Ces informations sont utilisees dans les documents de soumission. Elies 
seront ensuite citees en reference dans le contrat. Elies peuvent egalement etre utilisees lors de la preselection 
des fournisseurs ou faisant partie des criteres de selection. 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources inclut des 
informations sur les ressources qui seront acquises ou louees et egalement les hypotheses ou les contraintes 
susceptibles d'influencer I’approvisionnement. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. La reference de base du perimetre 
comprend I’enonce du perimetre, le WBS et le dictionnaire du WBS. Le perimetre du projet peut encore changer 
lors des premieres phases du projet. Les elements connus du perimetre permettent d'elaborer I’enonce des 
travaux et le cahier des charges. 

12.1.1.4 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. Cette liste des principaux jalons indique quand les vendeurs 
doivent livrer leurs resultats. 

♦ Affectations des membres de I’equipe projet. Elies sont decrites a la section 9.3.3.2. Les affectations des 
membres de I’equipe projet contiennent des informations sur les competences de I'equipe projet et sa disponibilite 
afin d’assurer les activites d'approvisionnement. Si I'equipe projet n’est pas qualifiee pour mener a bien les activites 
d’approvisionnement dont elle est responsable, il faudra obtenir d’autres ressources et/ou prevoir une formation. 
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♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences 
peut com porter: 

■ les exigences techniques auxquelles le vendeur doit se conformer; 

■ les exigences ayant des implications contractuelles et legates. Elies peuvent inclure la sante, la security 
la surete, la performance, I’environnement, les assurances, les droits de propriety intellectuelle, I’egalite 
d’acces a I’emploi, les licences, les permis ainsi que d'autres exigences non techniques. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des 
exigences associe les exigences du produit depuis leur origine jusqu’aux livrables correspondants. 

♦ Besoins en ressources. Ms sont decrits a lasection 9.2.3.1. Les besoins en ressources contiennent des informations 
sur des besoins specifiques comme les ressources materielles et humaines qu’il conviendrait d’acquerir. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques fournit une liste de risques, 
ainsi que les resultats de I’analyse des risques et la planification des reponses aux risques. Certains risques sont 
transfers via un accord d’approvisionnement. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes fournit des 
informations sur les participants au projet et leurs interets correspondants. II s'agit notamment des organismes 
de regimentation, du personnel en charge de la passation de marches et du personnel juridique. 

12.1.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus Planifier la 
gestion des approvisionnements, on peut citer: 

♦ les conditions du marche ; 

♦ les produits, les services et les resultats disponibles sur le marche; 

♦ les vendeurs, y compris leur performance passee ou leur reputation ; 

♦ les conditions generates typiques pour les produits, les services et les resultats, ou pour I’industrie en question ; 

♦ les exigences locales particulieres, comme les conditions reglementaires pour la main-d'oeuvre ou les 
vendeurs locaux; 

♦ les conseils juridiques concernant les approvisionnements ; 

♦ les systemes de gestion des contrats, y compris les procedures de gestion des changements des contrats ; 

♦ un systeme d’approvisionnement defini a plusieurs niveaux, avec des vendeurs prequalifies en fonction de 
I’experience passee; 

♦ un systeme de comptabilite financiere et de paiements contractuels. 
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12.1.1.6 ACTIFS ORGANISATIONNELS 


Les differents types d’accords contractuels conclus par I'organisation influent egalement sur les decisions au cours 
du processus Planifier la gestion des approvisionnements. Parmi les actifs organisationnels qui peuvent avoir une 
influence sur le processus Planifier la gestion des approvisionnements, on peut citer les elements suivants : 

♦ Listes des vendeurs preselectionnes. Les listes des vendeurs qui ont ete dument verifiees peuvent simplifier 
les etapes necessaires pour annoncer I’opportunite et reduire le delai de selection. 

♦ Politiques internes, procedures et directives formelles relatives aux approvisionnements. La plupart des 
organisations ont une politique interne etablie en matiere d’approvisionnement et des groupes charges des 
achats. Au cas ou ce type d’assistance aux approvisionnements ne serait pas disponible, I’equipe projet doit 
fournir a lafois les ressources et I’expertise necessaires pour effectuer de telles activites d’approvisionnement. 

♦ Types de contrat. De maniere generate, toutes les relations legates contractuelles font partie de I’une de deux 
grandes categories, a savoir les contrats a prix forfaitaire ou les contrats a frais remboursables. II existe, en outre, 
une troisieme categorie de type hybride, utilisee communement, et appelee « contrat en regie ». Les types de 
contrats les plus repandus sont traites ci-apres comme des types distincts. Toutefois, dans la pratique, il n’est 
pas rare d’associer un ou plusieurs types de contrat pour un meme approvisionnement. 

■ Contrats a prix forfaitaire. Cette categorie de contrats prevoit un prix total fixe pour un produit, un service ou 
un resultat a obtenir. Ces contrats sont utiles lorsque les exigences sont bien definies et si aucun changement 
important du perimetre n’est prevu. Les types de contrat a prix forfaitaire comprennent les elements suivants: 
o Contrat a prix ferme et definitif (Firm fixed price, FFP). II s’agit du type de contrat le plus repandu. II est 
prefere par la plupart des services des achats, car le prix des marchandises est fixe d’emblee et n’est pas 
sujet a modifications, a moins que le contenu du travail ne change, 
o Contrat a prix fixe avec interessement (Fixed price incentive fee, FPIF). Ce type de contrat a prix fixe 
confere une certaine flexibility a I'acheteur et au vendeur, car il permet des ecarts de performance, avec 
des clauses d’interessement liees a la realisation de metriques convenues. En general, ces clauses 
d’interessement sont liees au cout, a I’echeancier ou a la performance technique du vendeur. Dans le cas 
des contrats a prix fixe avec interessement, un prix plafond est defini, et tous les couts depassant ce prix 
plafond sont supportes par le vendeur. 

o Contrat a prix fixe avec indexation des prix. Ce type de contrat est utilise lorsque la periode de performance 
du vendeur s’etend sur un grand nombre d’annees ou si les paiements sont realises dans une devise 
differente. II s’agit d’un contrat au forfait, comportant toutefois une clause speciale permettant des 
revisions finales predefines du prix contractuel en raison de changements des conditions initiates, tels 
que les effets de I’inflation ou les variations des couts de matieres premieres. 
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♦ Contrats a frais remboursables. Cette categorie de contrat prevoit des paiements (des remboursements de 
couts) au vendeur pour tous les couts reels legitimes encourus pour le travail fourni, majores d'honoraires 
representant le profit du vendeur. Elle doit etre employee si un changement important du perimetre du travail 
est prevu lors de I’execution du contrat. II existe differentes versions. 

■ Contrat en regie avec honoraires fixes (Cost plus fixed fee, CPFF). Le vendeur est rembourse pour tous les 
couts autorises pour I'execution du contrat, et regoit en plus des honoraires fixes calcules sous forme de 
pourcentage de I'estimation initiale des couts du projet. Le montant des honoraires ne change pas, a moins 
que le perimetre du projet ne change. 

■ Contrat en regie avec interessement (Cost plus incentive fee, CPIF). Le vendeur est rembourse pour tous 
les couts autorises pour I’execution du contrat, et regoit en plus une prime d’interessement predeterminee 
basee sur la realisation de certains objectifs de performance definis dans le contrat. Dans le cas des contrats 
en regie avec interessement, si les couts finaux sont inferieurs ou superieurs aux couts initialement prevus, 
I'acheteur et le vendeur partagent tous deux les ecarts sur la base d’une formule de partage des couts 
prealablement negociee. Par exemple un partage 80/20 au-dessus ou en dessous des couts cibles, sur la 
base des performances reelles du vendeur. 

■ Contrat en regie avec prime a la performance (Cost plus award fee, CPAF). Le vendeur est rembourse pour 
tous les couts legitimes. Cependant, I’essentiel des honoraires est pergu sur la base de la satisfaction de 
certains criteres de performance generaux et relatifs definis et incorpores au contrat. Les honoraires sont 
determines uniquement sur la base du jugement subjectif des performances du vendeur par I’acheteur et ne 
peuvent pas faire, en general, I’objet d’une quelconque contestation. 

♦ Contrats en regie (Time and material contracts, T&M). Les contrats en regie (egalement appeles contrats 
pieces et main d’ceuvre) sont un type de contrat hybride comprenant a la fois certains aspects des contrats a 
frais remboursables et des contrats a prix forfaitaire. Ms sont souvent utilises pour le renforcement des effectifs, 
pour I’acquisition d'experts et pour toute assistance externe, lorsqu’il n’est pas possible d’etablir rapidement un 
enonce precis des travaux. 


12.1.2 PLANIFIER LA GESTION DES APPROVISIONNEMENTS : OUTILS ET TECHNIQUES 
12.1.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialises ou une formation dans les domaines suivants : 

♦ approvisionnement et achats; 

♦ types et documents de contrat; 

♦ regimentations et conformite. 
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12.1.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees dans le cadre de ce processus figure notamment 
I’etude de marche. L’etude de marche implique I'examen des aptitudes specifiques et industrielles des vendeurs. Les 
equipes en charge des achats peuvent exploiter les informations obtenues lors de conferences, les commentaires en 
ligne, et diverses autres sources, afin de determiner les capacites du marche. Ces equipes peuvent egalement affiner 
les objectifs specifiques en matiere d’approvisionnement, en vue de tirer parti de technologies en evolution, tout en 
equilibrant les risques par rapport a I’eventail de vendeurs capables de fournir les materiaux ou les services recherches. 

12.1.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figure notamment I'analyse 
« make-or-buy». Cette analyse permet de determiner si un travail ou des livrables peuvent etre accomplis de maniere 
satisfaisante par I’equipe projet, ou bien s’ils doivent etre acquis aupres de sources exterieures. Les facteurs a prendre 
en compte lors des decisions « make-or-buy»sont I'affectation des ressources actuelles et de leurs competences, le 
besoin d’une expertise specialist, le souhait de ne pas elargir les obligations des emplois permanents et le besoin 
d’une expertise independante. Elle comprend egalement revaluation des risques encourus dans le cadre d’une decision 
«make-or-buy». 

L’analyse«make-or-buy»peut s’appuyer sur le temps de retour sur investissement (payback period ou TRI), le retour 
sur investissement (ROI), le taux interne de rentabilite (IRR), la valeur actualisee des flux de tresorerie, la valeur actuelle 
nette (NPV), I'analyse cout-benefice (BCA) ou d’autres techniques afin de decider d’inclure un element dans le projet ou 
de I'acheter a I'exterieur. 

12.1.2.4 ANALYSE DE LA SELECTION DES SOURCES 

Avant de choisir une methode de selection, il est necessaire de revoir la hierarchisation des demandes concurrentes 
du projet. Les methodes de selection concurrentielle peuvent exiger des vendeurs d’investir beaucoup de temps et de 
ressources en amont. Ainsi, il est conseille de preciser la methode devaluation dans les documents d'approvisionnements 
a I'attention des soumissionnaires. Les methodes de selection couramment utilisees sont les suivantes : 

♦ Moindre cout. La methode du moindre cout peut convenir aux approvisionnements courants ou habituels dont 
les pratiques et les standards sont bien etablis et qui prevoient des resultats specifiques bien definis pouvant 
etre executes a differents couts. 

♦ Base sur les qualifications. La methode de selection basee sur les qualifications s’applique si le temps et le cout 
d’un processus de selection n'ont pas d’intereten raison de la valeur relativement faible de I'approvisionnement. 
L'acheteur etablit une breve liste et choisit le soumissionnaire ayant les meilleures qualifications, credibility 
experience, expertise, specialisations et references. 
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♦ Score de la meilleure proposition technique/qualite. L'entreprise selectionnee doit envoyer une proposition 
contenant des informations techniques et financieres. Ensuite, elle sera amenee a negocier le contrat si sa 
proposition technique est acceptable. Grace a cette methode, les propositions techniques sont tout d’abord 
evaluees en fonction de la qualite de la solution offerte. Le vendeur qui a presente la meilleure proposition 
technique est selectionne si sa proposition financiere peut etre negociee et acceptee. 

♦ Qualite et cout. La methode fondee sur la qualite et le cout permet d’inclure le facteur cout dans le processus 
de selection des vendeurs. En general, lorsque le risque et/ou I’incertitude sont plus importants pour le projet, la 
qualite doit etre un element cle par rapport au cout. 

♦ Source unique. L'acheteur demande a un vendeur precis de preparer des propositions techniques et financieres 
qui seront ensuite negociees. Etant donne I'absence de concurrence, cette methode convient uniquement si elle 
est dument justifiee et doit etre consideree comme une exception. 

♦ Budget fixe. La methode du budget fixe implique de communiquer le budget disponible aux soumissionnaires 
convies dans I'appel d’offres, puis de choisir la proposition technique la mieux classee, dans les limites du 
budget. Les soumissionnaires adapteront le perimetre et la qualite de leur offre a ce budget etant sujets a des 
contraintes de cout. L’acheteur doit done s’assurer que le budget est compatible avec I’enonce des travaux et que 
le vendeur sera a meme d’effectuer les taches dans les limites du budget. Cette methode convient uniquement 
lorsque I’enonce des travaux est defini de maniere precise, qu’aucun changement n’est anticipe et que le budget 
est fixe, sans possibility de depassement. 

12.1.2.5 REUNIONS 

L’etude de marche ne peut pas, a elle seule, fournir les informations necessaires pour etablir une strategie 
d’approvisionnement, si aucune reunion de partage des informations supplementaires n’est organisee avec les 
soumissionnaires eventuels. En collaborant avec les soumissionnaires potentiels, I’organisation achetant le materiel, 
ou le service, concerne peut beneficier d’informations utiles. Le vendeur peut influencer en faveur d’une approche ou 
d’un produit au benefice des deux parties. Les reunions permettent de determiner la strategie de gestion et de suivi 
des approvisionnements. 
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12.1.3 PLANIFIER LA GESTION DES APPROVISIONNEMENTS : DONNEES DE SORTIE 


12.1.3.1 PLAN DE GESTION DES APPROVISIONNEMENTS 

Le plan de gestion des approvisionnements comporte les activites a entreprendre durant le processus 
d’approvisionnement. II indique a quel type d'appel d’offres (international, national, local, etc.) il convient d’avoir recours. 
Si le projet beneficie d’un financement externe, les sources et la disponibilite des fonds doivent correspondre au plan 
de gestion des approvisionnements et a I'echeancier du projet. 

Le plan de gestion des approvisionnements peut comporter des directives pour: 

♦ la coordination de I’approvisionnement avec d’autres aspects du projet, comme I'elaboration de I’echeancier du 
projet et les processus de controle; 

♦ le calendrier des principales activites d’approvisionnement; 

♦ les metriques d’approvisionnement a utiliser pour gerer les contrats ; 

♦ les roles et responsabilites des parties prenantes en matiere d’approvisionnement, notamment I'autorite et les 
contraintes de I’equipe projet lorsque I'organisation realisable dispose d’un service d’approvisionnement; 

♦ les contraintes et les hypotheses susceptibles d’affecter les approvisionnements prevus; 

♦ la competence juridique et la devise de paiement; 

♦ la determination de I’utilisation d'estimations independantes et leur eventuelle necessity comme criteres 
d’evaluation; 

♦ les points a traiter en matiere de gestion des risques, y compris I’identification des exigences pour les garanties 
de bonne fin ou les contrats d’assurance, afin d’attenuer certains types de risques du projet; 

♦ les vendeurs prequalifies auxquels il est possible d’avoir recours, le cas echeant. 

Selon les besoins de chaque projet, un plan de gestion des approvisionnements peut etre formel ou informel, tres 
detaille ou formule de maniere generate. 
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12.1.3.2 STRATEGIE D’APPROVISIONNEMENT 


Apres avoir effectue I'analyse « make-or-buy » et pris la decision d'acquerir le projet d’une source exterieure, il 
convient d’identifier une strategie d’approvisionnement. L'objectif de la strategie d’approvisionnement est de determiner 
la methode de livraison des resultats du projet, le type d'accord(s) legal d’engagement mutuel(s) et I’avancement des 
approvisionnements au til des phases correspondantes. 

♦ Methodes de livraison. Les methodes de livraison ne sont pas les memes s’il s’agit de services professionnels 
ou de projets de construction. 

■ Pour les services professionnels, les methodes de livraison sont les suivantes : acheteur/prestataire de 
services sans sous-traitance, acheteur/prestataire de services avec sous-traitance autorisee, joint venture 
entre acheteur et prestataire de services et acheteur/prestataire de services agissant comme representant. 

■ Pour la construction commerciale ou industrielle, les principales methodes de livraison sont les suivantes: cle 
en main, conception-construction (DB), conception-soumission-construction (DBB), conception-construction- 
exploitation (DBO) et construction-possession-exploitation-transfert (BOOT). 

♦ Types de paiements contractuels. Les types de paiements contractuels sont distincts des methodes de livraison 
du projet. Ms sont coordonnes avec les systemes financiers internes de I’organisation acheteuse. Les types de 
paiements contractuels incluent notamment les types de contrat suivants avec des variantes : contrat a prix 
forfaitaire, contrat a prix ferme et definitif, contrat en regie avec prime a la performance, contrat en regie avec 
interessement, contrat en regie et contrat cout cible ou autres types de contrats. 

■ Les contrats a prix forfaitaire sont adaptes lorsqu’il est possible de prevoir le type des travaux et que les 
exigences sont bien definies et ne risquent pas de changer. 

■ Les contrats en regie sont adaptes lorsque les travaux evoluent, risquent de changer ou ne sont pas bien definis. 

■ Les primes et les interessements peuvent etre utilises pour aligner les objectifs de I'acheteur et du vendeur. 

♦ Phases de I’approvisionnement. La strategie d’approvisionnement peut egalement inclure des informations sur 
les phases de I’approvisionnement, notamment: 

■ I’ordonnancement par sequences ou par phases des activites d’approvisionnement, une description des 
phases et les objectifs specifiques pour chaque phase; 

■ les indicateurs de performance des approvisionnements et les jalons a utiliser pour leur suivi; 

■ les criteres pour passer d’une phase a I’autre; 

■ le controle et le plan devaluation pour suivre les progres realises ; 

■ le processus de transfert des connaissances a utiliser pour les phases suivantes. 
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12.1.3.3 DOCUMENTS D’APPEL D’OFFRES 


Les documents d’appel d'offres sont utilises pour solliciter des offres de la part de vendeurs potentiels. Les termes offre, 
soumission ou proposition de prix sont generalement utilises lorsque la decision du choix du vendeur repose sur le prix (dans 
le cas de I'achat d’articles distribues dans le commerce ou de type standard), tandis que le terme proposition est le plus 
souvent utilise lorsque d’autres considerations priment, telles que les competences techniques ou I’approche technique. 
La terminologie specifique aux approvisionnements peut varier selon I’industrie et la region d’approvisionnement. 

En fonction des biens ou des services requis, les documents de soumission se composent d’une demande d'information, 
d’une demande de devis, d’un appel d’offre ou d’autres documents d’approvisionnements appropries. Les conditions 
concernant leur utilisation sont presentees ci-dessous. 

♦ Demande d’information (Request for information, RFI). Une demande d'information permet d’obtenir aupres 
des vendeurs des informations complementaires sur les biens et les services a acheter. Elle est generalement 
suivie d’une demande de devis ou d’un appel d’offres. 

♦ Demande de devis (Request for Quotation, RFQ). Une demande de devis permet d’obtenir des informations 
complementaires sur la fagon dont les vendeurs pourraient repondre aux exigences et/ou sur le cout associe. 

♦ Appel d’offres (Request for proposal, RFP). L’appel d’offres est utilise en cas de probleme au niveau du projet 
et de difficulty a trouver la solution. II s'agit de la demande de documents la plus formelle. L'appel d’offres est 
assorti de regies d’approvisionnement strictes concernant le contenu, les delais et les reponses des vendeurs. 

L'acheteur structure les documents d’approvisionnements pour faciliter I'elaboration d’une reponse precise 
et complete de la part de chaque vendeur potentiel, ainsi que pour permettre une evaluation aisee des offres. Ces 
documents comprennent une description de la forme de reponse souhaitee, I’enonce des travaux d’approvisionnement 
approprie ettoutes les dispositions contractuelles requises. 

La complexity et le niveau de detail des documents d’approvisionnements doivent etre proportionnes a la valeur 
de I’approvisionnement planifie et aux risques qu'il presente. Les documents d’approvisionnement doivent etre 
suffisamment detailles pour assurer des reponses coherentes et adequates, mais suffisammentsouples pour permettre 
de prendre en compte les suggestions des vendeurs sur les meilleures fagons de satisfaire aux exigences. 

12.1.3.4 ENONCE DES TRAVAUX D’APPROVISIONNEMENT 

L’enonce des travaux pour chaque approvisionnement est elabore a partir de la reference de base du contenu du 
projet, et definit seulement la partie du perimetre du projet qui doit etre incluse dans le contrat concerne. L'enonce des 
travaux fournit une description suffisamment detaillee de I'article acquis pour permettre aux vendeurs potentiels de 
determiner s’ils sont en mesure de fournir les produits, les services ou les resultats en question. Le niveau de detail 
necessaire peut varier en fonction de la nature de I’article, des besoins de l’acheteur ou de la forme du contrat prevu. 
Les informations incluses dans un enonce des travaux peuvent comprendre les specifications, la quantity souhaitee, 
les niveaux de quality, les donnees de performance, les periodes de performance, les lieux d’execution du travail et 
d’autres exigences. 
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L'enonce des travaux d’approvisionnement doit etre formule de fagon claire, complete et concise. II comporte une 
description de tous les services auxiliaires requis, tels que les rapports d’avancement ou le support operationnel de 
I’element acquis apres la fin du projet. L'enonce des travaux peut etre revu au besoin au fur et a mesure qu’il progresse 
au sein du processus d’approvisionnement jusqu’a son incorporation dans un accord signe. 

L’expression Termes de Reference (TOR) est parfois utilisee lors de la conclusion de contrats de services. A I’instar 
de l'enonce des travaux d’approvisionnement, les termes de reference incluent generalement les elements suivants: 

♦ les taches confiees a I'entrepreneur ainsi que des exigences specifiques en matiere de coordination ; 

♦ les standards applicables au projet que I’entrepreneur doit respecter; 

♦ les donnees a soumettre pour approbation ; 

♦ une liste detaillee de toutes les donnees et de tous les services que I’acheteur fournit a I'entrepreneur a des fins 
d’execution du contrat, le cas echeant; 

♦ la definition de I'echeancier pour une presentation initiale et le delai de revision/approbation requis. 

12.1.3.5 CRITERES DE SELECTION DES SOURCES 

Lors du choix des criteres devaluation, I’acheteur cherche a s'assurer que la proposition choisie offrira la meilleure 
qualite pour les services requis. Les criteres de selection des sources peuvent comprendre, entre autres : 

♦ les aptitudes et capacites ; 

♦ le cout du produit et le cout du cycle de vie; 

♦ les dates de livraison ; 

♦ I’approche et I'expertise technique ; 

♦ I’experience appropriee; 

♦ le caractere adequat de la proposition d'approche et de plan de travail quant a l’enonce des travaux; 

♦ la qualification, la disponibilite et la competence du personnel cle; 

♦ la stability financier de I'entreprise; 

♦ I'experience en management; 

♦ la pertinence du programme de transfer! des connaissances, y compris la formation. 


478 


Premiere partie - Guide 



Dans le cadre des projets internationaux, les criteres devaluation incluent les exigences en matiere de « contenu 
local», par exemple, la participation de ressortissants locaux parmi le personnel cle propose. 

Les criteres particulars peuvent comprendre un score numerique, un code couleur ou une description ecrite de 
I’aptitude du vendeur a repondre aux besoins de I'organisation. Ces criteres feront partie d’un systeme de ponderation 
permettant de selectionner un vendeur a qui il sera demande de signer un contrat et d'etablir un deroulement de 
negotiation en classant toutes les propositions en fonction des scores devaluation ponderes attribues a chacune d’elles. 

12.1.3.6 DECISIONS « MAKE-OR-BUY >» 

Une analyse«make-or-buy»permet de determiner si un travail specifique peut etre accompli de maniere satisfaisante 
par I’equipe projet ou s’il doit etre achete aupres de sources exterieures. 

12.1.3.7 ESTIMATIONS INDEPENDANTES DES COUTS 

Pour les approvisionnements importants, I’organisation acheteuse peut soit preparer sa propre estimation 
independante, soit faire preparer une estimation des couts par un estimateur professionnel externe, aux fins de 
verification des reponses proposees. Des differences significatives dans les estimations des couts peuvent indiquer que 
I’enonce des travaux d’approvisionnement etait deficient, ambigu ou que les vendeurs potentiels ont soit mal compris 
I'enonce des travaux d’approvisionnement, soit manque d’y repondre dans son integrality. 

12.1.3.8 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Une decision impliquant I’approvisionnement de biens, de services ou de 
ressources peut necessiter une demande de changement. Lors de la planification de I'approvisionnement, d’autres 
decisions peuvent egalement generer le besoin de demandes de changement supplemental. Les demandes liees au 
plan de management du projet, a ses plans subsidiaires et a d’autres composants peuvent engendrer des demandes de 
changement qui influent sur les actions d’approvisionnement. Les demandes de changement sont passees en revue et 
traitees par le processus MaTtriser les changements (voir la section 4.6). 
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12.1.3.9 MISES A JOUR DES DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est 
mis a jour a I'aide des retours d’experience pertinents tires des regimentations, de la conformite, de la collecte 
et de I’analyse des donnees ainsi que de I’analyse de la selection des sources. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. Cette liste des principaux jalons indique quand les vendeurs 
doivent livrer leurs resultats. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut comporter: 

■ les exigences techniques que le vendeur doit satisfaire; 

■ les exigences ayant des implications contractuelles et legates. Elies incluent la sante, la securite, la surete, 
la performance, I'environnement, les assurances, les droits de propriety intellectuelle, I'egalite d’acces a 
I'emploi, les licences, les permis ainsi que d’autres exigences non techniques. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
lie les exigences du produit, depuis leur origine jusqu’aux livrables correspondents. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Chaque vendeur approuve comporte ses propres risques 
qui dependent de son organisation, de la duree de son contrat, de I'environnement exterieur, de la methode de 
livraison du projet, du type de mecanisme d’attribution de marches choisi et du prix final convenu. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes est mis 
a jour a I’aide d’informations complementaires sur les parties prenantes, en particulier les organismes de 
regimentation, le personnel contractuel et le personnel juridique. 
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12.1.3.10 MISES A JOUR DESACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui sont mis a jour a la suite du processus Planifier la gestion des approvisionnements 
figurent notamment les informations sur les vendeurs qualifies. 

Pour les projets necessitant des approvisionnements peu nombreux et relativement simples, certaines de ces 
donnees de sortie peuvent etre combinees. En revanche, pour les projets exigeant des approvisionnements complexes 
et importants et pour lesquels la majorite des travaux sont confies a des entrepreneurs, il existe differents types de 
documentation. Le tableau 12-1 est une liste representative des types de documents couramment utilises pour les 
approvisionnements et certains de leurs contenus. Etant donne la nature juridique des approvisionnements, cette liste 
ne doit pas etre consideree comme contraignante mais devrait, au contraire, etre utilisee comme un apergu general des 
types de documents et de contenus necessaires pour proceder aux approvisionnements. L’organisation, I’environnement 
et les contraintes juridiques dictent quels documents d’approvisionnements et informations sont necessaires au projet. 


Tableau 12-1. Comparaison des documents d’approvisionnements 


Plan de gestion 
des approvisionnements 

Strategic 

d’approvisionnement 

Enonce 
des travaux 

Documents 
d’appel d’offres 

Comment le travail 
d’approvisionnement sera 
coordonne et integre aux autres 
composants du projet, 
en particulier les ressources, 
I’echeancier et le budget 

Methodes de livraison des 
approvisionnements 

Description du sujet 
de I’approvisionnement 

Demande d’information (Request 
for information, RFI), demande 
de devis (Request for quote, 

RFQ), appel d’offre (Request for 
proposal, RFP) 

Calendrier des principales 
activites d’approvisionnement 

Types d’accords 

Specifications, exigences 
de qualite et metriques 
de performance 


Metriques d’approvisionnement 
pour gerer le contrat 

Phases de I’approvisionnement 

Description des services 
collateraux requis 


Responsabilites de toutes 
les parties prenantes 


Methodes et criteres 
d’acceptation 


Hypotheses et contraintes 
relatives aux 
approvisionnements 


Donnees de performance et 
autres rapports requis 


Competence juridique et devise 
utilisee pour le paiement 


Qualite 


Informations sur les estimations 
independantes 


Periode et lieu de performance 


Points a traiter en matiere 
de gestion des risques 


Devise, echeancier de paiement 


Vendeurs preselectionnes, 
le cas echeant 


Garantie 
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12.2 PROCEDER AUX APPROVISIONNEMENTS 


Proceder aux approvisionnements est le processus qui consiste a obtenir les reponses des vendeurs, a en selectionner 
un et a attribuer un contra! L’interet principal de ce processus est qu’il permet de selectionner un fournisseur qualifie 
et d’appliquer I’accord juridique necessaire a la livraison. Les resultats finaux du processus sont les accords etablis, y 
compris les contrats formels. Ce processus est execute periodiquement pendant toute la duree du projet. Les donnees 
d’entree, les outils, les techniques et les donnees de sortie du processus Proceder aux approvisionnements sont 
presentes a la figure 12-4. La figure 12-5 presente le diagramme de flux de donnees du processus. 


Proceder aux approvisionnements 


Donnees d’entree 


.1 Elaborer le plan 

de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion 
des exigences 

• Plan de gestion 

de la communication 

• Plan de gestion des risques 

• Plan de gestion 

des approvisionnements 

• Plan de gestion 

de la configuration 

• Reference de base 
des couts 

.2 Documents du projet 

• Registre des retours 
d'experience 

• Echeancier du projet 

• Documentation 
des exigences 

• Registre des risques 

• Registre des parties 
prenantes 

.3 Documents 

d'approvisionnements 
.4 Propositions des fournisseurs 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 

V_I_ J 


Outils et techniques 


.1 Jugement a dire d’expert 
.2 Publicity 
.3 Conferences 

des soumissionnaires 
.4 Analyse des donnees 

• Evaluation des propositions 
.5 Competences 

interpersonnelles et d'equipe 

• Negociation 

V _ ) 


Donnees de sortie 


.1 Vendeurs selectionnes 
.2 Accords 

.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 

• Plan de gestion 
des exigences 

• Plan de gestion de la qualite 

• Plan de gestion 

de la communication 

• Plan de gestion des risques 

• Plan de gestion 

des approvisionnements 

• Reference de base 
du perimetre 

• Reference de base 
de I'echeancier 

• Reference de base 
des couts 

.5 Mises a jour des documents 
du projet 

• Registre des retours 
d'experience 

• Documentation 
des exigences 

• Matrice de tragabilite 
des exigences 

• Calendriers des ressources 

• Registre des risques 

• Registre des parties 
prenantes 

.6 Mises a jour des actifs 
organisationnels 

— 


Figure 12-4. Proceder aux approvisionnements: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 



Plan de management du projet 

• Plan de gestion du perimetre 

• Plan de gestion des exigences 

• Plan de gestion de la communication 

• Plan de gestion des risques 

• Plan de gestion des approvisionnements 

• Plan de gestion de la configuration 

• Reference de base des couts 


Documents 
du projet 



Documents du projet 

• Registre des retours d’experience 

• Echeancier du projet 

• Documentation des exigences 

• Registre des risques 

• Registre des parties prenantes 


Documents 

d’approvision- 

nement 



Entreprise/ 

Organisation 


• Facteurs environnementaux 
de I'organisation 

• Actifs organisationnels 


Vendeurs 


• Propositions des fournisseurs 


12.2 

Proceder aux 
approvisionnements 


• Accords 



• Vendeurs 
selectionnes 


12.3 


Maitriser les 


approvisionnements 


.► 

• Demandes 
de changement 


4.6 

Effectuer 

la gestion integree 
des changements 


Plan 

de management 
du projet 


Mises a jour du plan 
de management du projet 

• Plan de gestion 
des exigences 

• Plan de gestion de la qualite 

• Plan de gestion de la communication 

• Plan de gestion des risques 

• Plan de gestion des approvisionnements 

• Reference de base du perimetre 
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Figure 12-5. Proceder aux approvisionnements: diagramme de flux de donnees 
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12.2.1 PROCEDER AUX APPROVISIONNEMENTS : DONNEES D’ENTREE 


12.2.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion du perimetre. II est decrit a la section 5.1.3.1. Le plan de gestion du perimetre decrit la 
methode de gestion du perimetre general des travaux, notamment le perimetre a realiser par les vendeurs. 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences decrit la 
maniere dont les exigences seront analysees, documentees et gerees. II peut inclure la fagon dont les vendeurs 
gereront les exigences a satisfaire en vertu de I'accord. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
decrit comment les communications entre les acheteurs et les vendeurs doivent etre gerees. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques est une composante 
du plan de management du projet et decrit la maniere dont les activites de gestion des risques seront structures 
et conduites pour le projet. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. Le plan de gestion des 
approvisionnements comporte les activites a entreprendre durant le processus Proceder aux approvisionnements. 

♦ Plan de gestion de la configuration. II est decrit a la section 5.6.1.1. Le plan de gestion de la configuration 
definit les elements qui sont configurables, ceux qui necessitent une maTtrise formelle des changements et le 
processus pour maTtriser les changements apportes a ces elements. II inclut les formats et les processus a I'aide 
desquels les vendeurs garantiront une gestion de la configuration conforme a I’approche de I’acheteur. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. La reference de base des couts inclut le 
budget pour les approvisionnements ainsi que les couts associes a la gestion des vendeurs et des processus 
d’approvisionnement. 

12.2.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du projet, 
relatifs a I’execution des approvisionnements, peuvent etre appliques aux phases ulterieures afin d’ameliorer 
I’efficacite de ce processus. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier du projet identifie les dates de debut et de 
fin des activites du projet, notamment les activites d'approvisionnement. II identifie egalement les echeances des 
livrables de I'entrepreneur. 
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♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences 
peut comporter: 

■ les exigences techniques que le vendeur doit satisfaire; 

■ les exigences ayant des implications contractuelles et legates. Elies incluent la sante, la securite, la surete, 
la performance, I’environnement, les assurances, les droits de propriety intellectuelle, I'egalite d’acces a 
I’emploi, les licences, les permis ainsi que d’autres exigences non techniques. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Chaque vendeur approuve comporte ses propres risques 
qui dependent de son organisation, de la duree de son contrat, de I'environnement exterieur, de la methode de 
livraison du projet, du type de mecanisme d’attribution de marches choisi et du prix final convenu. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Ce document contient tous les details 
concernant les parties prenantes identifies. 

12.2.1.3 DOCUMENTS D’APPROVISIONNEMENTS 

Les documents d’approvisionnements contiennent un enregistrement ecrit utilise pour parvenir a un accord juridique. 
Ils peuvent inclure des documents anterieurs au projet actuel. Les documents d’approvisionnements peuvent inclure les 
elements suivants: 

♦ Documents d’appei d’ottres. Ils sont decrits a la section 12.1.3.3. Les documents d'approvisionnements 
incluent la demande d’information, I’appel d’offres, la demande de devis ou tout autre document envoye aux 
vendeurs pour qu’ils puissent repondre a I'appel d’offres. 

♦ Enonce des travaux d’approvisionnement. II est decrit a la section 12.1.3.4. L'enonce des travaux 
d’approvisionnement donne aux vendeurs un ensemble d’objectifs, d’exigences et de resultats clairement definis, 
qui leur permet de formuler une reponse quantifiable. 

♦ Estimations independantes des couts. Elies sont decrites a la section 12.1.3.7. Les estimations independantes 
des couts sont realisees en interne ou par des ressources externes. Elies permettent de verifier le caractere 
raisonnable des propositions des soumissionnaires. 

♦ Criteres de selection des sources. Ils sont decrits a la section 12.1.3.5. Ces criteres decrivent le processus 
devaluation des propositions des soumissionnaires, y compris les criteres devaluation et leurs ponderations 
respectives. Pour I'attenuation des risques, I’acheteur peut decider de signer des accords avec plusieurs vendeurs 
afin de limiter les dommages causes par un vendeur ayant des problemes qui influencent I’ensemble du projet. 
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12.2.1.4 PROPOSITIONS DES FOURNISSEURS 


Les propositions des vendeurs, preparees en reponse a un dossier comportant des documents d’approvisionnements, 
torment les informations de base qu’un ou plusieurs evaluateurs utiliseront pour choisir un ou plusieurs des 
soumissionnaires retenus (vendeurs). Si le vendeur soumet une proposition de prix, la bonne pratique exige qu'elle soit 
distincte de la proposition technique. L’evaluateur examine chaque proposition en fonction des criteres de selection des 
sources. Ensuite, il selectionne le vendeur qui satisfait au mieux les exigences de I’organisation acheteuse. 

12.2.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I'organisation qui peuvent influencer le processus Proceder aux 
approvisionnements figurent notamment: 

♦ les lois et les regimentations locales relatives aux approvisionnements ; 

♦ les lois et les regimentations locales stipulant que is principaux approvisionnements doivent impliquer des 
vendeurs locaux; 

♦ I’environnement economique externe qui contraint is processus d’approvisionnement; 

♦ is conditions du marche ; 

♦ is informations concernant is experiences passees pertinentes avec des vendeurs, a la fois bonnes 
et mauvaises; 

♦ is accords anterieurs deja en place ; 

♦ is systemes de gestion des contrats. 

12.2.1.6 ACTIFS ORGANISATIONNELS 

Parmi is actifs organisationnels qui peuvent avoir une influence sur le processus Proceder aux approvisionnements, on 
peut citer: 

♦ la liste des vendeurs priviigies qui ont ete prequalifies ; 

♦ les politiques de I’organisation qui influencent le choix d’un vendeur; 

♦ is modeles ou is directives specifiques de I’organisation qui determineront la redaction et I’elaboration 
des accords; 

♦ is procedures et is politiques financiers concernant is processus de facturation et de paiement. 
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12.2.2 PROCEDER AUX APPROVISIONNEMENTS : OUTILS ET TECHNIQUES 


12.2.2.1 JUGEMENT A DIRE D’EXPERT 

II convient de faire appel a la competence decrite a la section 4.1.2.1 de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ evaluation des propositions ; 

♦ questions techniques ou autres; 

♦ domaines fonctionnels pertinents, comme les finances, I’ingenierie, la conception, le developpement et la gestion 
de la chaTne d’approvisionnement; 

♦ cadre reglementaire du secteur; 

♦ lois, regimentations et exigences en matiere de conformite; 

♦ negotiation. 

12.2.2.2 PUBLICITY 

Elle permet de communiquer avec les utilisateurs ou les utilisateurs potentiels d’un produit, d’un service ou d’un 
resultat. Les listes existantes de vendeurs potentiels peuvent souvent etre elargies en plagant des annonces dans 
des publications de grande diffusion, telles que des journaux selectionnes, ou dans des publications professionnelles 
specialists. La plupart des juridictions gouvernementales exigent la diffusion publique ou en ligne des contrats 
gouvernementaux en attente. 

12.2.2.3 CONFERENCES DES SOUMISSIONNAIRES 

Les conferences des soumissionnaires (egalement appelees conferences d’entrepreneurs, conferences defournisseurs 
ou conferences preliminaires a I’offre) sont des reunions avec I'acheteur et les vendeurs potentiels avant la soumission 
d’une proposition. Elies permettent de s'assurer que tous les soumissionnaires potentiels ont une comprehension claire 
et commune de I’approvisionnement et qu'aucun soumissionnaire ne beneficie de traitement preferentiel, 

12.2.2.4 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figure notamment revaluation 
des propositions. Les propositions sont evaluees afin de s'assurer qu’elles sont completes et respectent pleinement les 
documents de soumission, I'enonce des travaux d'approvisionnement, les criteres de selection des sources, ainsi que 
tout autre document du lot d’appels d’offres. 
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12.2.2.5 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 


Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figure la negociation. 
C’est une discussion visant a aboutir a un accord. La negociation permet de clarifier la structure, les droits, les obligations 
des parties et d’autres conditions auxquelles sont soumis les achats, de sorte qu'il soit possible de conclure des accords 
mutuels avant la signature du contrat. Les termes du document final refletenttous les accords conclus. Cette negociation 
se conclut par un document contractuel signe ou tout autre accord formel qui peut etre mis en execution par I'acheteur 
et par le vendeur. 

La negociation doit etre confiee a un membre de I’equipe approvisionnement habilite a signer des contrats. Le chef 
de projet ainsi que d’autres membres de I’equipe de management de projet peuvent etre presents lors des negociations 
pour fournir leur assistance, si necessaire. 


12.2.3 PROCEDER AUX APPROVISIONNEMENTS : DONNEES DE SORTIE 

12.2.3.1 VENDEURS SELECTIONNES 

Les vendeurs selectionnes sont ceux qui ont ete juges comme etant dans une fourchette competitive sur la base 
du resultat de revaluation de la proposition ou de I’offre. L’approbation finale des approvisionnements complexes, 
de grande valeur et a haut risque exige generalement I’approbation de la direction generate de I’organisation avant 
toute attribution. 
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12.2.3.2 ACCORDS 


Un contrat est un accord d’engagement mutuel par lequel le vendeur doit fournir les produits, les services ou les 
resultats specifies, en contrepartie duquel I’acheteur doit le payer. II represente une relation legale pouvant etre portee 
devant les tribunaux. Les composants principaux d’un document contractuel varient, et comprennent generalement: 

♦ I'enonce des travaux d’approvisionnement ou les principaux livrables ; 

♦ I’echeancier, les jalons ou la date a laquelle I'echeancier est requis; 

♦ les regies pour les rapports d’avancement; 

♦ les conditions de paiement et les tarifs ; 

♦ les criteres d’inspection, de qualite et d’acceptation ; 

♦ la garantie et la future assistance produit; 

♦ les mesures incitatives et les sanctions ; 

♦ I’assurance et les cautions de bonne execution ; 

♦ I’approbation des sous-traitants subordonnes ; 

♦ les conditions generates ; 

♦ le traitement des demandes de changement; 

♦ une clause de resiliation et des mecanismes de reglement extrajudiciaire des conflits. 

12.2.3.3 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Les demandes de changement du plan de management du projet, de ses 
plans subsidiaires et d’autres composants sont passees en revue et traitees par le processus MaTtriser les changements 
(voir la section 4.6). 
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12.2.3.4 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants du plan de management 
du projet qui peuvent exiger une demande de changement pour le plan de management du projet, on peut citer les 
elements suivants: 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Les exigences du projet peuvent evoluer si des 
vendeurs identifient des changements. 

♦ Plan de gestion de la qualite. II est decrit a la section 8.1.3.1. Les vendeurs peuvent proposer d’autres standards 
de qualite ou solutions qui ont un impact sur les principes de qualite definies dans le plan de gestion de la qualite. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Suite a I'engagement des vendeurs, le 
plan de gestion de la communication est mis a jour afin d’integrer leurs besoins et approches de communication. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Chaque accord et chaque vendeur comporte 
ses propres risques pouvant necessiter des mises a jour du plan de gestion des risques. Le registre des risques 
comporte egalement les risques specifiques. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. Les mises a jour peuvent etre 
necessaires en fonction des resultats des processus d’attribution de contrat et de negotiation. 

♦ Reference de base du perimetre. Elle est decrite a la section 5.4.3.1. Le WBS et les livrables du projet, 
documents dans la reference de base du perimetre du projet, sont pris en consideration lors de I’execution 
des activites d'approvisionnement. Certains de ces aspects, voire tous, peuvent changer lors du processus 
d’approvisionnement. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. En cas de changement de livraison de la 
part des vendeurs ayant des consequences sur la performance generate de I’echeancier du projet, il est possible 
que la reference de base de I'echeancier doive etre mise a jour et approuvee pour refleter les attentes actuelles. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les prix des materiaux et des entrepreneurs 
peuvent changer frequemment au cours de la livraison d’un projet. Ces changements sont dus a la fluctuation 
des prix des materiaux et de la main d’ceuvre creee par I’environnement economique exterieur. Ils doivent etre 
integres a la reference de base des couts. 
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12.2.3.5 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour a I’aide des informations sur les difficulty rencontrees lors des approvisionnements, sur les moyens pour 
les eviter et sur les approches qui ont le mieux fonctionne. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences 
peut comporter: 

■ les exigences techniques que le vendeur doit satisfaire; 

■ les exigences ayant des implications contractuelles et legales. Elies comprennent la sante, la securite, la 
surete, la performance, I'environnement, les assurances, les droits de propriete intellectuelle, I’egalite d’acces 
a I'emploi, les licences, les permis ainsi que d'autres exigences non techniques. 

♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. Avec I’integration des vendeurs au 
plan du projet, le registre des exigences et la matrice de tragabilite correspondante peuvent changer en fonction 
des aptitudes du vendeur. 

♦ Calendriers des ressources. Ils sont decrits a la section 9.2.1.2. Les calendriers des ressources de I’echeancier 
peuvent necessiter une mise a jour en fonction des disponibilites des vendeurs. 

♦ Registre des risques. II est decrit a la section 11.2.3.1 . Chaque vendeur approuve comporte ses propres risques 
qui dependent de son organisation, de la duree de son contrat, de I’environnement exterieur, de la methode 
de livraison du projet, du type de mecanisme d'attribution de marches choisi et du prix final convenu. Les 
changements sont apportes au registre des risques lors du processus d’attribution de contrat qui refletent les 
risques propres a chaque vendeur. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Ce document contient tous les details 
concernant les parties prenantes identifies. Le registre des parties prenantes est mis a jour lorsque des accords 
sont conclus avec des vendeurs. 

12.2.3.6 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les elements des actifs organisationnels pouvant etre mis a jour a la suite du processus Proceder aux 
approvisionnements, on peut citer les elements suivants : 

♦ les listes de vendeurs potentiels et prequalifies ; 

♦ les informations concernant les experiences pertinentes avec des vendeurs, a la fois bonnes et mauvaises. 
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12.3 MAITRISER LES APPROVISIONNEMENTS 


MaTtriser les approvisionnements est le processus qui consiste a gerer les relations fournisseurs, a suivre I’execution 
du contrat, a effectuer les changements et corrections appropries et a clore les contrats. L’interet principal de ce 
processus est qu’il permet de s’assurer que les performances du vendeur et de I'acheteur satisfont les exigences 
du projet, conformement a I'accord legal. Ce processus est execute pendant toute la duree du projet en fonction des 
besoins. Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a la 
figure 12-6. La figure 12-7 presente le diagramme de flux de donnees de ce processus. 
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Figure 12-6. Maitriser les approvisionnements: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 12-7. Maitriser les approvisionnements: diagramme de flux de donnees 
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L'acheteur et le vendeur gerent le contrat d’approvisionnement a des fins similaires. Chacun doit s'assurer que 
les deux parties remplissent leurs obligations contractuelles et que leurs droits respectifs sont proteges. La nature 
juridique des relations impose que I’equipe de management de projet ait connaissance des implications des demarches 
entreprises dans le cadre du controle de tout approvisionnement. Pour les projets de grande envergure, comprenant 
plusieurs fournisseurs, un aspect cle de la gestion des contrats reside dans la gestion des communications entre les 
divers fournisseurs. 

En raison de son aspect juridique, de nombreuses organisations considered la gestion des contrats comme une 
fonction organisationnelle distincte du projet. Tandis qu’un administrateur des approvisionnements peutfaire partie de 
I’equipe projet, il se trouve generalement sous I’autorite du responsable d’un autre service. 

MaTtriser les approvisionnements comprend I’application des processus de management de projet adaptes aux 
relations contractuelles et I’integration des donnees de sortie de ces processus dans le management global du projet. 
Cette integration a souvent lieu a differents niveaux, lorsque plusieurs vendeurs entrent en jeu pour des produits, des 
services ou des resultats multiples. 

Parmi les activites administratives, on peut citer: 

♦ la collecte des donnees et la gestion des enregistrements du projet, notamment la maintenance des 
enregistrements detailles des performances techniques et financiers mais aussi I’etablissement d’indicateurs 
mesurables de performance des approvisionnements; 

♦ le perfectionnement des echeanciers et des plans d’approvisionnement; 

♦ I’organisationde la collecte, del’analyseetdelacommunicationdesdonneesduprojetlieesauxapprovisionnements 
et I’elaboration de rapports periodiques pour I’organisation ; 

♦ le suivi du contexte des approvisionnements en vue de faciliter I’application ou d’apporter des ajustements; 

♦ le paiement des factures. 

La qualite des controles, notamment I’independance et la credibility des audits d’approvisionnement, est essentielle 
afin de garantir la fiabilite du systeme d’approvisionnement. Le code de deontologie de I'organisation, son conseiller 
juridique ainsi que ses dispositions en matiere de conseils juridiques externes, notamment toute initiative de lutte contre 
la corruption, peuvent contribuer aux controles des approvisionnements en place. 

MaTtriser les approvisionnements comporte un composant de gestion financier qui implique la surveillance des 
paiements effectues au vendeur. Ceci assure que les conditions de paiement definies dans le contrat sont respectees 
et que la contrepartie est liee aux progres du vendeur, comme defini dans le contrat. L'existence d’une relation etroite 
entre les paiements effectues aux fournisseurs et le travail qu’ils ont accompli est la premiere preoccupation au moment 
d’effectuer les paiements. Un contrat qui necessite des paiements bases sur les livrables et les donnees de sortie du 
projet au lieu des donnees d’entree, comme les heures de travail, possede de meilleurs controles. 

Avant leur cloture, les accords peuvent faire I'objet d’amendements a tout moment par consentement mutuel, 
conformement aux clauses contractuelles de gestion des changements. Ces changements sont generalement indiques 
par ecrit. 
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12.3.1 MATTRISER LES APPROVISIONNEMENTS : DONNEES D’ENTREE 


12.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.3.2. Le plan de gestion des exigences decrit la 
maniere dont les exigences de ^entrepreneur seront analysees, documentees et gerees. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques decrit la maniere 
dont les activites a risque creees par les vendeurs seront structures et executees dans le cadre du projet. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.2. Le plan de gestion des 
approvisionnements comporte les activites a effectuer durant le processus MaTtriser les approvisionnements. 

♦ Plan de gestion des changements. II est decrit a la section 4.2.3.1. Le plan de gestion des changements 
contient des informations sur la prise en charge des changements introduits par les vendeurs. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. En cas de derapages de la part des 
vendeurs ayant des consequences sur la performance globale du projet, il est possible que I'echeancier doive 
etre mis a jour et approuve pour refleter les attentes actuelles. 

12.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses documente les hypotheses 
emises lors du processus d’approvisionnement. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du 
projet peuvent etre appliques ulterieurement afin d’ameliorer la performance de I’entrepreneur et le processus 
d’approvisionnement. 

♦ Liste des jalons. Elle est decrite a la section 6.2.3.3. Cette liste des principaux jalons indique a quel moment les 
vendeurs doivent livrer leurs resultats. 

♦ Rapports de qualite. Ms sont decrits a la section 8.2.3.1. Les rapports de qualite identifient les processus, les 
procedures ou les produits du vendeur qui ne sont pas conformes. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. La documentation des exigences peut comporter: 

■ les exigences techniques que le vendeur doit satisfaire; 

■ les exigences ayant des implications contractuelles et legales. Elies comprennent la sante, la securite, la 
surete, la performance, I’environnement, les assurances, les droits de propriete intellectuelle, I’egalite d’acces 
a I'emploi, les licences, les permis ainsi que d’autres exigences non techniques. 
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♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
lie les exigences du produit, depuis leur origine jusqu’aux livrables correspondents. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Chaque vendeur approuve comporte ses propres risques 
qui dependent de son organisation, de la duree de son contrat, de I'environnement exterieur, de la methode de 
livraison du projet, du type de mecanisme d’attribution de marches choisi et du prix final convenu. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes inclut des 
informations sur les parties prenantes identifies, notamment les membres d’equipe sous contrat, les vendeurs 
selectionnes, les agents contractuels et les autres parties prenantes qui participent aux approvisionnements. 

12.3.1.3 ACCORDS 

lls sont decrits a la section 12.2.3.2. Les accords sont des arrangements conclus entre les parties, incluant les obligations 
de chaque partie. Les accords pertinents sont passes en revue afin de verifier le respect des conditions generates. 

12.3.1.4 DOCUMENTS D’APPROVISIONNEMENTS 

Les documents d’approvisionnements contiennent les dossiers complets pour la gestion des processus 
d’approvisionnement. lls incluent I’enonce des travaux d’approvisionnement, les informations relatives au paiement, les 
informations sur la performance d’execution du cocontractant, les plans, les dessins ainsi que toute autre correspondence. 

12.3.1.5 DEMANDES DE CHANGEMENT APPROUVEES 

Elies sont decrites a la section 4.6.3.1. Les demandes de changement approuvees peuvent comprendre les 
changements des conditions generates du contrat, y compris de I'enonce des travaux d’approvisionnement, du prix et la 
description des produits, des services ou des resultats a fournir. Tous les changements lies aux approvisionnements sont 
formellement documents par ecrit et approuves avant d’etre mis en oeuvre dans le cadre du processus Martriser les 
approvisionnements. Pour les projets et les programmes complexes, les demandes de changement peuvent provenir de 
vendeurs qui participent au projet et peuvent influencer d’autres vendeurs. Le projet doit pouvoir identifier, communiquer 
et resoudre les changements ayant des effets sur le travail des divers vendeurs. 

12.3.1.6 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent les donnees des 
vendeurs sur I’etat du projet, comme la performance technique, les activites qui ont demarre, sont en cours ou ont ete 
achevees mais aussi les couts encourus ou engages. Ces donnees peuvent egalement inclure des informations sur les 
factures payees aux vendeurs. 
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12.3.1.7 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I'organisation qui peuvent avoir une influence sur le processus MaTtriser 
les approvisionnements, on peut citer: 

♦ le systeme de martrise des modifications du contrat; 

♦ les conditions du marche ; 

♦ le systeme de comptes fournisseurs et de gestion financier; 

♦ le code de deontologie de I'organisation acheteuse. 

12.3.1.8 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser les approvisionnements 
figurent notamment les politiques d’approvisionnement. 


12.3.2 MAITRISER LES APPROVISIONNEMENTS : OUTILS ET TECHNIQUES 
12.3.2.1 JUGEMENT A DIRE D’EXPERT 

II convient de faire appel a la competence decrite a la section 4.1.2.1 de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ domaines fonctionnels pertinents, comme les finances, I’ingenierie, la conception, le developpement et la gestion 
de la chaTne d’approvisionnement; 

♦ lois, regimentations et exigences en matiere de conformite; 

♦ gestion des reclamations. 
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12.3.2.2 GESTION DES RECLAMATIONS 

Les changements contestes et les ameliorations possibles sont des demandes de changement dans lesquels acheteurs 
et vendeurs ne peuvent se mettre d’accord sur la nature du changement lui-meme ou sur son dedommagement. Ces 
changements contestes sont appeles reclamations. Lorsque ceux-ci ne peuvent etre resolus, ils aboutissent a des 
differends, puis des appels. Les reclamations sont documentees, traitees, surveillees et gerees tout au long du cycle de 
vie du contrat, generalement en accord avec les conditions generates du contrat. Si les parties elles-memes ne trouvent 
pas de solution a une reclamation, il est possible que celle-ci doive etre traitee conformement aux modes alternatifs de 
resolution des conflits definis dans le contrat. Le reglement de tous les differends et les reclamations par la negociation 
est la methode privilegiee. 

12.3.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour suivre et martriser les approvisionnements 
figurent notamment les elements suivants: 

♦ Revues de performance. Les revues de performance des contrats mesurent, comparent et analysent la 
performance de la qualite, des ressources, de I'echeancier et des couts par rapport a I'accord. Ceci inclut 
I’identification des lots de travaux qui sont en avance ou en retard par rapport a I’echeancier, depassent ou 
respectent le budget ou encore presented des problemes de ressources ou de qualite. 

♦ Analyse de la valeur acquise (Earned Value Management, EVM). Elle est decrite a la section 7.4.2.2. Les 

ecarts de couts et d’echeancier ainsi que les indices de performance des couts et de I'echeancier sont calcules 
afin de determiner le degre d’ecart par rapport a I'objectif fixe. 

♦ Analyse de la tendance. Elle est decrite a la section 4.5.2.2. L'analyse de la tendance permet d’etablir une 
prevision du cout estime a terminaison (EAC) afin de voir si la performance des couts s'ameliore ou, au contraire, 
se deteriore. Consultez la section 7.4.2.2 pour en savoir plus sur les methodes de prevision du cout estime a 
terminaison. 

12.3.2.4 INSPECTION 

Une inspection est une revue structure des travaux realises par I'entrepreneur. II peut s’agir d’une simple revue des 
livrables ou d’un examen physique reel des travaux. Dans le cas d’un projet de construction/conception/infrastructure, 
les inspections incluent des visites du site par I’acheteur et I’entrepreneur afin de garantir une comprehension mutuelle 
des travaux en cours. 

12.3.2.5 AUDITS 

Les audits, decrits a la section 8.2.2.5, sont une revue structure du processus d’approvisionnement. Les droits et 
les obligations lies aux audits doivent etre decrits dans le contrat d’approvisionnement. Les observations suite a I’audit 
doivent etre portees a I’attention des chefs de projet de I'acheteur et du vendeur, respectivement, quant aux eventuels 
ajustements a apporter au projet. 
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12.3.3 MAITRISER LES APPROVISIONNEMENTS : DONNEES DE SORTIE 


12.3.3.1 APPROVISIONNEMENTS CLOS 

L'acheteur, generalement via son gestionnaire des approvisionnements autorise, transmet au vendeur la notification 
ecrite formelle que le contrat a ete complete. Les exigences relatives a la cloture formelle des approvisionnements 
sont habituellement definies dans les conditions generates du contrat et sont comprises dans le plan de gestion des 
approvisionnements. En general, tous les livrables sont fournis dans les delais et doivent satisfaire aux exigences 
techniques et de qualite, Aucune reclamation ni aucun facteur ne doit rester en suspens. Tous les paiements finaux 
doivent avoir ete effectues. L'equipe de management de projet doit avoir approuve tous les livrables avant la cloture. 

12.3.3.2 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d’execution permet de connaTtre la performance 
d’un vendeur en comparant les livrables obtenus, la performance technique atteinte et les couts encourus et acceptes 
par rapport au budget de renonce des travaux pour les travaux realises. 

12.3.3.3 MISES A JOUR DES DOCUMENTS D’APPROVISIONNEMENTS 

Parmi les documents d’approvisionnement qui peuvent etre mis a jour figurent le contrat avec tous les echeanciers 
correspondants, les demandes de changement du contrat non approuvees et les demandes de changement approuvees. 
Les documents d’approvisionnements comprennent egalementtoute documentation technique elaboree par le vendeur 
et toute autre information sur la performance du travail, telle que les livrables, les rapports d’avancement du vendeur, 
les garanties, les documents financiers, y compris les factures, les enregistrements de paiement et les resultats des 
inspections liees au contrat. 

12.3.3.4 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Les demandes de changement du plan de management du projet, de ses plans 
subsidiaires et d’autres composants, telles que la reference de base des couts, la reference de base de I'echeancier et le 
plan de gestion des approvisionnements, peuvent resulter du processus MaTtriser les approvisionnements. Les demandes 
de changement sont passees en revue et traitees par le processus MaTtriser les changements (voir la section 4.6). 

Les changements demandes, mais non resolus, peuvent inclure des directives fournies par l'acheteur ou des actions 
entreprises par le vendeur, que I'autre partie considere comme un changement implicite force du contrat. Puisque 
chacune de ces ameliorations peut etre contestee par une des parties et conduire a une reclamation contre I’autre 
partie, de tels changements sont identifies de maniere unique et documents dans la correspondance du projet. 
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12.3.3.5 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I'organisation par I’intermediaire d’une demande de changement. Parmi les composants qui peuvent exiger une 
demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Chaque accord et chaque vendeur comporte 
ses propres risques pouvant necessiter des mises a jour du plan de gestion des risques. Le plan de gestion des 
risques peut exiger une mise a jour si d’importants risques imprevus surviennent durant I’execution du contrat. 
Le registre des risques comporte egalement les risques specifiques. 

♦ Plan de gestion des approvisionnements. II est decrit a la section 12.1.3.1. Le plan de gestion des 
approvisionnements comporte les activites a entreprendre durant le processus d’approvisionnement. Des mises 
a jour peuvent etre necessaires en fonction des resultats de la performance des vendeurs lors de I’execution 
des travaux. 

♦ Reference de base de I’echeancier. Elle est decrite a la section 6.5.3.1. Si les vendeurs suscitent d’importants 
changements au niveau de I’echeancier ets’ils affectent la performance generate de I’echeancier du projet, il est 
possible que la reference de base de I’echeancier doive etre mise a jour et approuvee pour refleter les attentes 
actuelles. L’acheteur doit etre conscient du fait que tout retard dans I’echeancier de la part d’un vendeur peut 
avoir des effets en cascade sur les autres vendeurs. 

♦ Reference de base des couts. Elle est decrite a la section 7.3.3.1. Les couts pour les materiaux et les 
entrepreneurs peuvent changer frequemment au cours de la livraison d’un projet. Ces changements sont dus a 
la fluctuation des prix des materiaux et de la main d’oeuvre creee par I'environnement economique exterieur. Ms 
doivent etre integres a la reference de base des couts. 

12.3.3.6 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience peut 
etre mis a jour a I'aide des techniques qui se sont revelees efficaces pour conserver le perimetre, I’echeancier et 
le cout des articles fournis. En cas d'ecart, le registre presente les actions correctives utilisees pour y faire face 
ainsi que leur efficacite. Si des reclamations sontfaites, les informations doivent etre documentees afin d’eviter 
qu’elles ne se represented. II est egalement possible de consigner les informations complementaires sur la 
fagon d’ameliorer le processus d’approvisionnement. 

♦ Besoins en ressources. Ms sont decrits a la section 9.2.3.1. Avec I'avancement des travaux des entrepreneurs, 
les besoins en ressources peuvent changer en raison d’un ecart entre le travail realise et I’echeancier prevu 
des travaux. 
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♦ Matrice de tragabilite des exigences. Elle est decrite a la section 5.2.3.2. La matrice de tragabilite des exigences 
est mise a jour a I'aide des informations sur les exigences qui ont ete satisfaites. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Chaque vendeur approuve comporte ses propres risques 
qui dependent de son organisation, de la duree de son contrat, de I’environnement exterieur, de la methode 
de livraison du projet, du type de mecanisme d’attribution de marches choisi et du prix final convenu. Les 
changements sont apportes au registre des risques lors de I'execution du projet, etant donne que les premiers 
risques ne s’appliquent plus et que de nouveaux risques apparaissent. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. A mesure que les travaux progressent au 
cours de la phase d’execution, les entrepreneurs et les fournisseurs peuvent changer. Ces changements doivent 
apparaTtre dans le registre des parties prenantes. 

12.3.3.7 MISES A JOUR DES ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels pouvant etre mis a jour suite au processus MaTtriser les approvisionnements, on 
peut citer les elements suivants : 

♦ Echeanciers et demandes de paiement. Tous les paiements doivent etre effectues conformement aux 
conditions generates du contrat. 

♦ Documentation sur revaluation de la performance du vendeur. La documentation sur revaluation de la 
performance du vendeur est elaboree par I’acheteur. Elle documente I’aptitude du vendeur a continuer d’executer 
le travail au titre du contrat actuel, indique si le vendeur peut etre autorise a effectuer le travail pour de futurs 
projets ou mesure I’efficacite dontfait ou a fait preuve le vendeur dans I'execution du travail du projet. 

♦ Mises a jour des listes des vendeurs prequalifies. Les listes des vendeurs prequalifies sont les listes des 
vendeurs potentiels qui sont prealablement qualifies (approuves). Ces listes seront mises a jour en fonction des 
resultats du processus MaTtriser les approvisionnements. En effet, des vendeurs pourraient etre disqualifies et 
supprimes des listes en cas de mauvaise performance. 

♦ Archive des retours d’experience. Les retours d’experience doivent etre consignes dans I’archive correspondante 
afin d'ameliorer les approvisionnements dans le cadre de projets ulterieurs. Au terme du contrat, les resultats 
reels de I'approvisionnement sont compares aux resultats prevus du plan de gestion des approvisionnements 
d’origine. Ces retours d’experience indiquent si les objectifs du projet ont ete atteints et, dans le cas contraire, 
les raisons de leur echec. 

♦ Dossier d’approvisionnement. Un ensemble complet indexe de la documentation du contrat, y compris le 
contrat clos, est prepare pour incorporation aux dossiers finaux du projet. 
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GESTION DES PARTIES PRENANTES DU PROJET 

Processus requis pour identifier les personnes, les groupes ou les organisations susceptibles d’affecter ou d’etre 
affectes par le projet, pour analyser les attentes des parties prenantes et leur impact sur le projet, mais aussi pour 
developper des strategies de gestion appropriees afin de mobiliser efficacement les parties prenantes en les impliquant 
dans les decisions du projet et son execution. Ces processus permettent a I’equipe projet d’analyser les attentes 
des parties prenantes, d’evaluer dans quelle mesure elles affectent ou sont affectees par le projet et d’elaborer des 
strategies afin de les faire participer de maniere efficace dans la prise de decision du projet mais aussi la planification 
et I'execution du travail du projet. 

Les processus de gestion des parties prenantes du projet sont les suivants : 

13.1 Identifier les parties prenantes —est le processus qui consiste a identifier regulierement les parties 
prenantes du projet mais aussi a analyser et a documenter des informations pertinentes concernant leurs interets, leur 
participation, leurs interdependences, leur influence et leur impact potentiel sur la reussite du projet. 

13.2 Planifier I’engagement des parties prenantes —est le processus qui consiste a developper des approches 
pour impliquer les parties prenantes du projet, en fonction de leurs besoins, de leurs attentes, de leurs interets et de leur 
impact potentiel sur le projet. 

13.3 Gerer I’engagement des parties prenantes —est le processus qui consiste a communiquer et a travailler 
avec les parties prenantes afin de satisfaire leurs besoins et leurs attentes, de gerer les points a traiter et de les 
encourager a participer de maniere adequate. 

13.4 MaTtriser I’engagement des parties prenantes —est le processus qui consiste a maitriser les relations avec 
les parties prenantes du projet et a adapter les strategies et les plans afin d’encourager leur engagement. 

La figure 13-1 donne une vue d’ensemble des processus de gestion des parties prenantes du projet. Les processus 
de gestion des parties prenantes du projet sont presenters comme des processus distincts aux interfaces clairement 
definies tandis que, dans la pratique, ils se chevauchent et interagissent de differentes manieres qui ne peuvent pas etre 
completement detaillees dans le Guide PMBOK®. 
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Vue d’ensemble du management 
des parties prenantes du projet 


13.1 Identifier 
les parties prenantes 


.1 Donnees d'entree 

.1 Elaborer la charte du projet 
.2 Documents business 
.3 Elaborer le plan 
de management du projet 
.4 Documents du projet 
.5 Accords 
.6 Facteurs 
environnementaux 
de I'organisation 
.7 Actifs organisationnels 

.2 Outils ettecbniques 
.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Representation 
des donnees 
.5 Reunions 

.3 Donnees de sortie 
.1 Registre des parties 
prenantes 

.2 Demandes de cbangement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour 
des documents du projet 

V_ J 


13.2 Flanifier 
l’engagement 
des parties prenantes 


.1 Donnees d'entree 
.1 Elaborer la charte 
du projet 

.2 Elaborer le plan 

de management du projet 
.3 Documents du projet 
.4 Accords 
.5 Facteurs 
environnementaux 
de I’organisation 
.6 Actifs organisationnels 

.2 Outils ettechniques 

.1 Jugement a dire d'expert 
.2 Collecte des donnees 
.3 Analyse des donnees 
.4 Prise de decision 
.5 Representation 
des donnees 
.6 Reunions 

.3 Donnees de sortie 
.1 Plan d'engagement 
des parties prenantes 

V _/ 


13.3 Gerer l’engagement 
des parties prenantes 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Facteurs 
environnementaux 
de I'organisation 
.4 Actifs organisationnels 

.2 Outils ettechniques 
.1 Jugement a dire d'expert 
.2 Competences 
en communication 
.3 Competences 
interpersonnelles 
et d'equipe 
.4 Regies de base 
.5 Reunions 

.3 Donnees de sortie 
.1 Demandes de cbangement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour 
des documents du projet 
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13.4 Maitriser 
l’engagement 
des parties prenantes 


.1 Donnees d'entree 
.1 Elaborer le plan 
de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d’execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

.2 Outils ettecbniques 
.1 Analyse des donnees 
.2 Prise de decision 
.3 Representation 
des donnees 
.4 Competences 
en communication 
.5 Competences 
interpersonnelles et 
d'equipe 
.6 Reunions 

.3 Donnees de sortie 
.1 Information sur 
la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

V _/ 


Figure 13-1. Vue d’ensemble du management des parties prenantes du projet 


PRINCIPAUX CONCEPTS DE LA GESTION DES PARTIES PRENANTES DU PROJET 

Chaque projet comporte des parties prenantes susceptibles d’affecter le projet, ou d’etre affectees par celui-ci de 
fagon positive ou negative. Certaines parties prenantes peuvent avoir un impact limite sur le travail ou les resultats 
du projet; d’autres peuvent avoir une influence significative sur celui-ci et sur les resultats que Ton en attend. Les 
recherches et analyses universitaires realisees sur divers echecs retentissants de projets soulignent I’importance d’une 
approche structure de I’identification, de la priorisation et de I’engagement de toutes les parties prenantes. La capacite 
du chef de projet et de I’equipe a correctement identifier et mobiliser ces parties prenantes de maniere appropriee peut 
faire la difference entre le succes et I’echec. Pour augmenter les chances de succes, le processus d’identification et 
d'engagement des parties prenantes doit commencer le plus tot possible apres I’approbation de la charte du projet, la 
designation du chef de projet et la creation de I'equipe. 
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La satisfaction des parties prenantes doit etre identifiee et geree comme un objectif du projet. La cle d’un engagement 
efficace des parties prenantes reside dans une communication continue avec ces dernieres, notamment les membres 
de I’equipe, pour comprendre leurs besoins et leurs attentes, pour traiter les problemes au fur et a mesure qu’ils se 
presentent, pour gerer les interets contradictoires et pour promouvoir un engagement adequat des parties prenantes 
dans les decisions et les activites du projet. 

Le processus d’identification et d’engagement des parties prenantes au benefice du projet est iteratif. Alors que les 
processus de gestion des parties prenantes du projet ne sont decrits qu’une seule fois, les activites d’identification, de 
priorisation et d’engagement doivent, elles, etre passees en revue et mises a jour regulierement, notamment lorsque : 

♦ le projet passe a une autre phase de son cycle de vie; 

♦ les parties prenantes actuelles ne sont plus impliquees dans le travail du projet ou de nouvelles parties prenantes 
prennent part au projet; 

♦ I’organisation ou la communaute elargie des parties prenantes est soumise a des changements importants. 

TENDANCES ET PRATIQUES EMERGENTES EN GESTION DES PARTIES PRENANTES DU PROJET 

Les parties prenantes feront I’objet de definitions plus generates afin d'inclure non seulement les traditionnelles 
categories des employes, des fournisseurs et des parties prenantes mais aussi les groupes, comme les organismes 
de reglementation, les lobbys, les environnementalistes, les institutions financieres, les medias et les personnes qui 
estiment etre des parties prenantes, car elles sont affectees par le travail ou les resultats du projet. 

Les tendances et pratiques emergentes en gestion des parties prenantes du projet incluent notamment les 
elements suivants: 

♦ identifier toutes les parties prenantes et pas seulement un ensemble limite; 

♦ s'assurer que tous les membres de I’equipe participent aux activites d’engagement des parties prenantes; 

♦ revoir regulierement la communaute des parties prenantes, le plus souvent en parallele aux revues des risques 
individuels du projet; 

♦ consulter les parties prenantes les plus affectees par le travail ou les resultats du projet grace au concept de 
co-creation. La co-creation insiste davantage sur I’integration dans I'equipe des parties prenantes concernees 
en tant que partenaires. 

♦ La valeur, tant positive que negative, de I’engagement efficace des parties prenantes est consignee. La valeur 
positive peut se fonder sur revaluation des benefices d’un support plus actif des parties prenantes, notamment 
de celles qui sont influentes. La valeur negative peut etre mesuree par les couts reels d’un engagement inefficace 
des parties prenantes, entrainant des rappels de produits ou la perte de reputation de I'organisation ou du projet. 
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CONSIDERATIONS RELATIVES A L’ADAPTATION 


Chaque projet etant unique, il peut s’averer necessaire pour le chef de projet d’adapter la fagon dont les processus 
de gestion des parties prenantes du projet sont appliques. Parmi les considerations relatives a I’adaptation, on peut citer 
les elements suivants: 

♦ Diversity des parties prenantes. Combien y a-t-il de parties prenantes ? Dans quelle mesure la culture au sein 
de la communaute des parties prenantes est-elle diversifiee ? 

♦ Complexity des relations entre les parties prenantes. Dans quelle mesure les relations au sein de la 
communaute des parties prenantes sont-elles complexes ? Plus une partie prenante ou un groupe de parties 
prenantes participe a des reseaux, plus la partie prenante est susceptible de recevoir des reseaux d’information 
et de disinformation complexes. 

♦ Technologie de communication. Quelle est la technologie de communication disponible ? Quels mecanismes 
de support ont ete mis en place pour garantir la plus forte valeur ? 

CONSIDERATIONS RELATIVES AUX ENVIRONNEMENTS AGILES/ADAPTATIFS 

Les projets soumis a de grands changements necessitent un engagement actif de la part des parties prenantes du 
projet. Afin de faciliter les discussions et les prises de decision productives et opportunes, des equipes agiles preferent 
entrer en contact direct avec les parties prenantes au lieu de passer par la hierarchie. Le client, I’utilisateur et le 
concepteur echangent souvent des informations selon un processus creatif dynamique qui suscite une plus grande 
participation des parties prenantes et resulte en une plus grande satisfaction. Les interactions regulieres avec les 
parties prenantes tout au long du projet permettent de limiter les risques, d’instaurer une confiance et d’encourager 
des adaptations introduces au plus tot dans le cycle du projet. Ainsi, les couts sont reduits, et les chances de reussite 
du projet sont accrues. 

En vue d’accelerer le partage des informations au sein de I'organisation, les methodes agiles promeuvent la 
transparence. L'invitation des parties prenantes aux reunions et aux revues du projet ou a la diffusion des documents 
du projet dans des espaces publics a pour but de faire ressortir les eventuels decalages, dependances ou autres points 
a traiter lies a revolution du projet. 
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13.1 IDENTIFIER LES PARTIES PRENANTES 


Identifier les parties prenantes est le processus qui consiste a identifier regulierement les parties prenantes du projet 
mais aussi a analyser et a documenter des informations pertinentes concernant leurs interets, leur participation, leurs 
interdependances, leur influence et leur impact potentiel sur la reussite du projet. L'interet principal de ce processus 
est qu’il permet a I’equipe projet d'identifier I’orientation a suivre pour chaque partie prenante ou groupe de parties 
prenantes. Ce processus est execute periodiquement pendant toute la duree du projet. Les donnees d’entree, les outils, 
les techniques et les donnees de sortie de ce processus sont presentes a la figure 13-2. La figure 13-3 presente le 
diagramme de flux de donnees du processus. 


Identifier les parties prenantes 


Donnees d’entree V Outils et techniques W Donnees de sortie 


.1 Elaborer la charte du projet 
.2 Documents business 

• Business case 

• Plan de gestion 
des benefices 

.3 Elaborer le plan 

de management du projet 

• Plan de gestion 
de la communication 

• Plan d’engagement 
des parties prenantes 

.4 Documents du projet 

• Journal des changements 

• Journal des points a traiter 

• Documentation 
des exigences 

.5 Accords 

.6 Facteurs environnementaux 
de I’organisation 
.7 Actifs organisationnels 

V___ 


.1 Jugement a dire d'expert 
.2 Collecte des donnees 

• Questionnaires et enquetes 

• Brainstorming 

.3 Analyse des donnees 

• Analyse des parties 
prenantes 

• Analyse des documents 

.4 Representation des donnees 

• Cartographie/representation 
des parties prenantes 

.5 Reunions 

V_y 


.1 Registre des parties 
prenantes 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 

• Plan de gestion 
des exigences 

• Plan de gestion 

de la communication 

• Plan de gestion des risques 

• Plan d'engagement 
des parties prenantes 

.4 Mises a jour des documents 
du projet 

• Journal des hypotheses 

• Journal des points a traiter 

• Registre des risques 

V ___/ 


Figure 13-2. Identifier les parties prenantes: donnees d’entree, outils, techniques et donnees de sortie 
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• Facteurs environnementaux 
de I'organisation 

• Actifs organisationnels 


Figure 13-3. Identifier les parties prenantes: diagramme de flux de donnees 


Ce processus intervient souvent pour la premiere fois avant ou parallelement a la redaction et a I’approbation de la 
charte du projet. Ce processus est reitere autant que necessaire. II doit neanmoins etre execute au debut de chaque 
phase et lorsqu’un changement important est apporte au projet ou a I’organisation. A chaque iteration du processus 
d’identification, les elements du plan de management du projet et les documents du projet doivent etre consultes afin 
d’identifier les parties prenantes cles du projet. 
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13.1.1 IDENTIFIER LES PARTIES PRENANTES : DONNEES D’ENTREE 


13.1.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet contient la liste des principales parties prenantes et peut aussi 
inclure des informations sur leurs responsabilites. 

13.1.1.2 DOCUMENTS BUSINESSS 

Lors de la premiere iteration du processus Identifier les parties prenantes, le business case et le plan de gestion des 
benefices constituent les sources d’informations sur les parties prenantes du projet. 

♦ Business case. II est decrit a la section 1.2.6.1. Le business case identifie les objectifs du projet et repertorie les 
parties prenantes affectees par le projet. 

♦ Plan de gestion des benefices. II est decrit a la section 1.2.6.2. Le plan de gestion des benefices decrit les 
mesures prevues pour concretiser les benefices decrits dans le business case. II peut identifier les personnes et 
les groupes qui profiteront des resultats du projet et sont done considers comme des parties prenantes. 

13.1.1.3 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Le plan de management du projet n’est pas disponible lors de la premiere identification 
des parties prenantes. Une fois elabores, les elements de ce plan sont notamment les suivants: 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Les communications et I’engagement des 
parties prenantes sont etroitement lies. Les informations contenues dans le plan de gestion de la communication 
constituent une source de connaissances sur les parties prenantes du projet. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des 
parties prenantes identifie les actions et les strategies de gestion necessaires pour engager efficacement les 
parties prenantes. 
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13.1.1.4 DOCUMENTS DU PROJET 


II est peu probable que les documents du projet soient des donnees d'entree de la premiere identification des parties 
prenantes. Cette operation d’identification intervient neanmoins tout au long du projet. Lorsque le projet a termine sa 
phase de demarrage, d’autres documents deviennent accessibles et sont utilises au fil du projet. Parmi les documents 
du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus figurent notamment les 
elements suivants: 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Le journal des changements peut introduire une 
nouvelle partie prenante ou changer la nature de la relation d’une partie prenante existante par rapport au projet. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Ce journal consigne les points a traiter qui 
peuvent introduire de nouvelles parties prenantes au projet ou changer le type de participation des parties 
prenantes existantes. 

♦ Documentation des exigences. Elle est decrite a la section 5.2.3.1. Les exigences peuvent contenir des 
informations sur les parties prenantes potentielles. 

13.1.1.5 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Les parties a un accord sont des parties prenantes du projet. L'accord peut faire 
reference a d’autres parties prenantes. 

13.1.1.6 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Identifier les 
parties prenantes, on peut citer: 

♦ la culture de I’organisation, le climat politique et le cadre de gouvernance ; 

♦ les standards gouvernementaux ou industriels (regimentations, standards de produits et codes de conduite); 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 

13.1.1.7 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Identifier les parties prenantes, on 
peut citer: 

♦ les modeles des registres des parties prenantes et les instructions ; 

♦ les registres des parties prenantes des projets anterieurs; 

♦ I’archive des retours d’experience contenant des informations sur les preferences, les mesures et I’implication 
des parties prenantes. 
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13.1.2 IDENTIFIER LES PARTIES PRENANTES : OUTILS ET TECHNIQUES 


13.1.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ comprehension des politiques et des structures de pouvoir de I’organisation ; 

♦ connaissance de I’environnement et de la culture de I’organisation et des autres organisations concernees, y 
compris les clients et le contexte etendu ; 

♦ connaissance du secteur ou du type de livrables du projet; 

♦ connaissance de I'expertise et des contributions des membres de I'equipe. 

13.1.2.2 COLLECTE DES DONNEES 

Parmi les techniques de collecte des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Questionnaires et enquetes. Ils sont decrits a la section 5.2.2.2. Les questionnaires et les enquetes peuvent 
inclure les evaluations individuelles, les seances de groupes de discussion ou toute autre technique de collecte 
d’informations de masse. 

♦ Brainstorming/Brainwriting. II est decrit a la section 4.1.2.2. Lorsque le brainstorming est utilise pour identifier 
les parties prenantes du projet, il se compose d’une reflexion collective verbale (brainstorming) et d’une reflexion 
ecrite (brainwriting). 

■ Brainstorming (verbal). II s'agit d’une technique generate de collecte des donnees et de creativite qui permet 
d’obtenir des donnees d’entree de groupes, telles que les membres d’equipe ou les experts sur le sujet. 

■ Brainwriting (ecrit). II s’agit d’une forme elargie du brainstorming qui accorde plus de temps aux participants 
pour se pencher sur chacune des questions avant la seance de creativite en groupe. Les informations peuvent 
etre recueillies au sein de groupes individuels ou a I’aide d’environnements virtuels grace a la technologie. 
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13.1.2.3 ANALYSE DES DONNEES 


Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des parties prenantes. L’analyse des parties prenantes permet d’obtenir une liste des parties prenantes 
et des informations pertinentes, comme leur poste dans I’organisation, leurs roles par rapport au projet, leurs « 
enjeux», leurs attentes, leurs comportements (niveaux de support au projet) et leur interet pour les informations 
liees au projet. Parmi les enjeux des parties prenantes figurent notamment les elements suivants : 

■ Interet. Une personne ou un groupe peut etre affecte par une decision liee au projet ou a ses resultats. 

■ Droits (legauxou moraux). Les droits legaux, comme la sante et la securite au travail, peuvent etre definis dans 
le cadre legislate d’un pays. Les droits moraux peuvent s'accompagner de concepts, tels que la protection 
des sites historiques ou la durabilite environnementale. 

■ Propriete. Une personne ou un groupe possede un titre de propriete. 

■ Connaissances. Les connaissances specialises peuvent etre utiles au projet, car elles permettent d’atteindre 
plus efficacement ses objectifs, les resultats de I’organisation ou les connaissances des structures de pouvoir 
de I’organisation. 

■ Contribution. L’apport de fonds ou d’autres ressources, notamment des ressources humaines, ou I’offre d’un 
support plus intangible au projet, comme une communication sous forme de promotion des objectifs du 
projet ou le fait de servir d’intermediaire entre le projet et les structures de pouvoir de I’organisation et de 
ses politiques. 

♦ Analyse des documents. Elle est decrite a la section 5.2.2.3. II s’agit de revaluation de la documentation 
disponible du projet et des retours d’experience de projets anterieurs dans le but d’identifier les parties prenantes 
et autres informations de support du projet. 

13.1.2.4 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figure notamment la 
cartographie/representation des parties prenantes. La ca rtog ra p h i e/re pres e ntatio n des parties prenantes permet de 
classer les parties prenantes a I'aide de differentes methodes. Le classement des parties prenantes permet a I’equipe 
d’etablir des relations avec les parties prenantes identifies du projet. Parmi les methodes courantes figurent les 
elements suivants: 

♦ Matrice pouvoir/interet, matrice pouvoir/influence ou matrice impact/influence. Chacune de ces techniques 
regroupe les parties prenantes selon leur niveau d’autorite (pouvoir), leur niveau d’engagement envers les resultats 
du projet (interet), leur aptitude a influencer les resultats du projet (influence) ou a susciter des changements de 
la planification ou de I’execution du projet. Ces modeles de classification sont utiles pour les petits projets ou les 
projets comportant des relations simples entre les parties prenantes et le projet ou au sein de la communaute 
des parties prenantes elle-meme. 
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♦ Cube des parties prenantes. II s'agit d’une forme perfectionnee des modeles de matrice mentionnes plus haut. 
Ce modele associe les elements des matrices en un modele en trois dimensions qui peut etre utile aux chefs de 
projet et a leurs equipes afin d’identifier et d’engager les parties prenantes. Le cube des parties prenantes fournit 
un modele aux dimensions multiples qui ameliore la representation de la communaute des parties prenantes en 
tant qu'entite multidimensionnelle. De plus, il contribue a elaborer les strategies de communication. 

♦ Modele de predominance. II decrit des classes de parties prenantes sur la base des evaluations de leur pouvoir 
(niveau d’autorite ou capacite a influencer les resultats du projet), de I’urgence (besoin d’attention immediate, 
avec contrainte de temps ou lie aux enjeux de haut niveau des parties prenantes) et de leur legitimite (pertinence 
de leur participation). II existe une adaptation du modele de predominance qui remplace la proximite par la 
legitimite (application a I’equipe et mesure de leur niveau d'implication dans le travail du projet). Le modele de 
predominance est plus utile pour les grandes communautes de parties prenantes ou les reseaux complexes 
de relations avec la communaute. Ce modele est egalement utile pour definir I'importance relative des parties 
prenantes identifies. 

♦ Orientation de I’influence. II s’agit du classement des parties prenantes selon leur influence sur le travail du 
projet ou sur I’equipe projet. Les parties prenantes peuvent etre classees comme suit: 

■ ascendante (la direction generate de I’organisation realisatrice ou de I'organisation cliente, le sponsor et le 
comite de direction); 

■ descendants (I’apport de connaissances ou de competences de I’equipe ou des specialistes a une 
capacite temporaire); 

■ sortante (les groupes de parties prenantes et leurs representants en dehors de I’equipe projet, comme les 
fournisseurs, les organes gouvernementaux, le public, les utilisateurs finaux et les organismes de regulation); 

■ laterale (les pairs du chef de projet, comme les autres chefs de projet ou les responsables intermediates qui 
sont en concurrence pour I'obtention des ressources limitees du projet ou qui collaborent avec le chef de 
projet afin de partager les ressources ou informations). 

♦ Priorisation. La priorisation des parties prenantes peuts’averer necessaire pour les projets qui en reunissent un 
grand nombre, lorsque leur appartenance a la communaute change frequemment, quand les relations entre elles 
et I’equipe projet ou au sein de la communaute elle-meme sont complexes. 
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13.1.2.5 REUNIONS 


Les reunions permettent de mieux comprendre les parties prenantes cles du projet. Elies peuvent se presenter sous 
la forme d’ateliers, de discussions dirigees en petits groupes et de groupes virtuels en utilisant les technologies des 
reseaux sociaux ou I'electronique afin de partager les idees et d’analyser les donnees. 


13.1.3 IDENTIFIER LES PARTIES PRENANTES : DONNEES DE SORTIE 

13.1.3.1 REGISTRE DES PARTIES PRENANTES 

Le registre des parties prenantes est la donnee de sortie principale du processus Identifier les parties prenantes. Ce 
document contient des informations sur les parties prenantes identifies, notamment les suivantes : 

♦ Informations ^identification. Le nom, le poste dans I'organisation, les coordonnees et le role au sein du projet. 

♦ Informations devaluation. Les principales exigences, les attentes, I’influence potentielle sur les resultats du 
projet et la phase du cycle de vie pour laquelle la partie prenante a le plus d’impact. 

♦ Classification des parties prenantes. Le modele de classification interne/externe, impact/influence/pouvoir/ 
interet, ascendante/descendante/sortante/laterale ou autre choisi par le chef de projet. 

13.1.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Aucune demande de changement ne serafaite lors de la premiere identification 
des parties prenantes. Au fur et a mesure des identifications des parties prenantes tout au long du projet, I’ajout de 
nouvelles parties prenantes, ou de nouvelles informations les concernant, peut conduire a une demande de changement 
du produit, du plan de management du projet ou des documents du projet. 

Les demandes de changement sont passees en revue et traitees par le processus Maitriser les changements (voir la 
section 4.6). 
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13.1.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Lors de la toute premiere identification des parties prenantes, le plan de management du projet ne sera soumis a 
aucune mise a jour. A mesure que le projet avance, tout changement apporte au plan de management du projet est 
soumis a la gestion des changements par I'intermediaire d’une demande de changement. Parmi les composants qui 
peuvent exiger une demande de changement pour le plan de management du projet, on peut citer les elements suivants : 

♦ Plan de gestion des exigences. II est decrit a la section 5.1.1.2. Les parties prenantes recemment identifiees 
peuvent influencer la planification, le suivi et la documentation des activites liees aux exigences. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Les exigences en communication 
des parties prenantes et les strategies de communication convenues sont consignees dans le plan de gestion de 
la communication. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques contient les 
exigences en communication des parties prenantes et les strategies de communication convenues qui affectent 
la gestion des risques du projet. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Les strategies de communication 
convenues des parties prenantes identifiees sont consignees dans le plan d’engagement des parties prenantes. 

13.1.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I'execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. La plupart des informations sur le pouvoir relatif, 
I’interet et I’engagement des parties prenantes se fondent sur des hypotheses. Ces informations sont saisies dans 
le journal des hypotheses. De plus, toute contrainte associee ayant une interaction avec des parties prenantes 
specifiques y est egalement consignee. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les nouveaux points a traiter souleves suite a ce 
processus sont consignes dans le registre correspondent. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Les nouveaux risques identifies lors de ce processus 
sont consignes dans le registre des risques, puis geres a I’aide des processus de gestion des risques. 
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13.2 PLANIFIER L’ENGAGEMENT DES PARTIES PRENANTES 


Planifier I’engagement des parties prenantes est le processus qui consiste a developper des approches pour 
impliquer les parties prenantes du projet, en fonction de leurs besoins, de leurs attentes, de leurs interets et de leur 
impact potentiel sur le projet. L'interet principal de ce processus est qu’il fournit un plan d’action concret pour interagir 
efficacement avec les parties prenantes. Ce processus est execute periodiquement pendant toute la duree du projet. 

Les donnees d’entree, les outils, les techniques et les donnees de sortie de ce processus sont presentes a lafigure 13-4. 
La figure 13-5 presente le diagramme de flux de donnees du processus. 




.1 Elaborer la charte du projet 
.2 Elaborer le plan 

de management du projet 
• Plan de gestion 


.1 Jugement a dire d'expert 
.2 Collecte des donnees 


• Benchmarking 
.3 Analyse des donnees 


.1 Plan d'engagement 
des parties prenantes 




des ressources 
• Plan de gestion 


• Analyse des hypotheses et 
des contraintes 

• Analyse des causes 


de la communication 
• Plan de gestion des risques 


originelles 
.4 Prise de decision 


.3 Documents du projet 

• Journal des hypotheses 

• Journal des changements 

• Journal des points a traiter 

• Echeancier du projet 

• Registre des risques 

• Registre des parties 


• Priorisation/classement 
.5 Representation des donnees 


prenantes 
.6 Reunions 


• Mind maps 

• Matrice devaluation 

de I'engagement des parties 


prenantes 


.4 Accords 


V 


.5 Facteurs environnementaux 
de I'organisation 


.6 Actifs organisationnels 


Figure 13-4. Planifier I’engagement des parties prenantes: donnees d’entree, outils, techniques et donnees de sortie 
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Plan 

de management 
du projet 


• Facteurs environnementaux 
de (’organisation 

• Actifs organisationnels 


Figure 13-5. Planifier I’engagement des parties prenantes: diagramme de flux de donnees 
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Un plan efficace reconnaissant les differents besoins en information des parties prenantes du projet est elabore 
au debut du cycle de vie du projet. Ce plan est ensuite passe en revue et mis a jour regulierement pour tenir compte 
des changements dans la communaute des parties prenantes. La premiere version du plan d’engagement des parties 
prenantes est redigee apres la premiere identification de celles-ci grace au processus Identifier les parties prenantes. 
Ce plan est regulierement mis a jour afin de refleter les changements dans la communaute des parties prenantes. Parmi 
les situations qui exigent generalement des mises a jour du plan figurent notamment: 

♦ le debut d’une nouvelle phase du projet; 

♦ les changements apportes a la structure de I’organisation ou au sein du secteur industriel; 

♦ I’arrivee de nouvelles personnes ou de nouveaux groupes en tant que parties prenantes, le depart de parties 
prenantes de la communaute ou une modification de I'importance de certaines d’entre elles par rapport a la 
reussite du projet; 

♦ la revue des strategies d’engagement des parties prenantes imposee par des donnees de sortie provenant 
d’autres domaines du projet, comme la gestion des changements, des risques ou des points a traiter. 

Les resultats de ces adaptations peuvent etre des changements apportes a I'importance relative des parties prenantes 
identifies. 


13.2.1 PLANIFIER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES D’ENTREE 

13.2.1.1 CHARTE DU PROJET 

Elle est decrite a la section 4.1.3.1. La charte du projet contient des informations sur le but, les objectifs et les criteres 
de reussite du projet qu’il convient de prendre en compte lorsque I’on planifie I'engagement des parties prenantes. 

13.2.1.2 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources peut contenir 
des informations sur les roles et responsabilites de I’equipe et des autres parties prenantes figurant dans le 
registre des parties prenantes. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Les strategies de communication et 
leurs plans d'application sont des donnees d’entrees et des destinataires des informations des processus de 
gestion des parties prenantes du projet. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques peut decrire des 
seuils de risque ou des attitudes vis-a-vis des risques qui aident a choisir les meilleures strategies d’engagement 
des parties prenantes. 
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13.2.1.3 DOCUMENTS DU PROJET 


Parmi les documents du projet susceptibles d’etre considers comme des donnees d'entree pour ce processus, en 
particulier apres la premiere planification, figurent notamment les elements suivants: 

♦ Journal des hypotheses. II est decrit a la section 4.1.3.2. Le journal des hypotheses contient des informations 
sur les hypotheses et les contraintes. II peut etre relie a des parties prenantes specifiques. 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Le journal des changements contient les changements 
apportes au perimetre d’origine du projet. II est generalement relie aux parties prenantes qui ont soit demande 
certains changements, soit pris des decisions concernant les demandes de changement, ou ont ete affectees par 
I’application des changements approuves. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. La gestion et la resolution des points a traiter contenus 
dans le journal correspondant necessitent davantage de communications avec les parties prenantes concernees. 

♦ Echeancier du projet. II est decrit a la section 6.5.3.2. L'echeancier contient des activites pouvant etre reliees a 
des parties prenantes specifiques designees comme responsables ou executants. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques contient les risques identifies du 
projet generalement relies aux parties prenantes specifiques designees comme charges de risque ou sujets a 
I’impact du risque. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes fournit la liste 
des parties prenantes du projet mais aussi des donnees de classification et d’autres informations. 

13.2.1.4 ACCORDS 

Ms sont decrits a la section 12.2.3.2. Lors de la planification de I’engagement des sous-traitants et des fournisseurs, 
la coordination implique generalement de collaborer avec le groupe en charge de I'approvisionnement/sous-traitance 
afin de garantir une gestion efficace des sous-traitants et des fournisseurs. 

13.2.1.5 FACTEURS ENVIRONNEMENTAUX DE ^ORGANISATION 

Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Planifier 
I’engagement des parties prenantes, on peut citer: 

♦ la culture de I’organisation, le climat politique et le cadre de gouvernance ; 

♦ les politiques d’administration du personnel; 

♦ I’appetence au risque des parties prenantes; 

♦ les canaux de communication etablis ; 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 
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13.2.1.6 ACTIFS ORGANISATIONNELS 


Parmi les actifs organisationnels qui peuvent influencer sur le processus Planifier I'engagement des parties prenantes, 
on peut citer: 

♦ les politiques et les procedures de I'organisation relatives aux reseaux sociaux, a la deontologie et a la securite; 

♦ les politiques et les procedures de I’organisation relatives aux points a traiter, aux risques, au changement et a 
la gestion des donnees ; 

♦ les exigences de I'organisation en matiere de communication ; 

♦ les directives standardises sur elaboration, I'echange, la conservation et la recuperation des informations; 

♦ I’archive des retours d’experience contenant des informations sur les preferences, les mesures et I’implication 
des parties prenantes; 

♦ les outils logiciels necessaires pour entretenir I’engagement efficace des parties prenantes. 

13.2.2 PLANIFIER L’ENGAGEMENT DES PARTIES PRENANTES : OUTILS ET TECHNIQUES 

13.2.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialist ou une formation dans les domaines suivants : 

♦ politiques et structures du pouvoir de I'organisation et en dehors de I’organisation ; 

♦ environnement et culture de I’organisation et en dehors de I’organisation ; 

♦ techniques analytiques et devaluation a utiliser pour les processus d’engagement des parties prenantes ; 

♦ moyens et strategies de communication ; 

♦ connaissances acquises de projets anterieurs concernant les caracteristiques des parties prenantes, des groupes 
de parties prenantes et des organisations impliques dans le projet actuel susceptibles d’avoir participe a des 
projets anterieurs similaires. 

13.2.2.2 COLLECTE DES DONNEES 

Le benchmarking est une des techniques de collecte des donnees qui peut notamment etre utilisee pour ce processus. 
II est decrit a la section 8.1.2.2. Les resultats de I'analyse des parties prenantes sont compares aux informations 
provenant d'autres organisations ou projets ayant une renommee globale. 
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13.2.2.3 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des hypotheses et des contraintes. Elle est decrite a la section 11 .2.2.3. L’analyse des hypotheses et 
des contraintes actuelles peut etre entreprise afin d'elaborer des strategies d’engagement appropriees. 

♦ Analyse des causes originelles. Elle est decrite a la section 8.2.2.2. L'analyse des causes originelles identifie 
les raisons sous-jacentes du niveau de support des parties prenantes au projet dans le but de choisir la meilleure 
strategie pour ameliorer leur niveau d’engagement. 

13.2.2.4 PRISE DE DECISION 

Parmi les techniques de prise de decision pouvant etre utilisees pour ce processus figurent notamment la priorisation/ 
le classement. Les exigences des parties prenantes doivent etre priorisees/classees, tout comme les parties prenantes. 
Les parties prenantes qui ont le plus d’interet et la plus grande influence sont souvent classees en haut de la liste. 

13.2.2.5 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Mind mapping. II est decrit a la section 5.2.2.3. Le mind mapping permet d’organiser visuellement les 
informations sur les parties prenantes ainsi que les relations entre elles et I’organisation. 

♦ Matrice devaluation de I’engagement des parties prenantes. Cette matrice permet de comparer les niveaux 
actuels et souhaites d’engagement des parties prenantes qui sont requis pour aboutir au succes du projet. La 
figure 13-6 presente une fagon de classer le niveau d’engagement des parties prenantes. Le niveau d'engagement 
des parties prenantes peut etre classe comme suit: 

■ Inconscient. Inconscient du projet et de ses impacts potentiels. 

■ Resistant. Conscient du projet et de ses impacts potentiels, mais resistant aux changements pouvant survenir 
suite au travail ou aux resultats du projet. Ces parties prenantes ne supporteront ni le travail ni les resultats 
du projet. 

■ Neutre. Conscient du projet, mais, pour autant, ni favorable ni defavorable. 

■ Supportif. Conscient du projet et de ses impacts potentiels; supporte le travail et ses resultats. 

■ Leader. Conscient du projet et de ses impacts potentiels; activement engage a garantir la reussite du projet. 
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La figure 13-6 C presente le niveau actuel d’engagement des parties prenantes. La figure 13-6 D indique le niveau que 
I’equipe projet a estime comme essentiel pour garantir la reussite du projet (niveau souhaite). Cet ecart entre le niveau 
actuel et le niveau souhaite orientera les communications necessaires pour entretenir efficacement I’engagement des 
parties prenantes. II est essentiel de combler cet ecart afin de martriser I’engagement des parties prenantes. 
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Resistant 

Neutre 

Supportif 

Leader 

Partie prenante 1 
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D 
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Partie prenante 3 




DC 



Figure 13-6. Matrice devaluation de I’engagement des parties prenantes 


13.2.2.6 REUNIONS 

Les reunions permettent de discuter et d’analyser les donnees d’entree du processus de planification de I'engagement 
des parties prenantes et d'elaborer un plan d'engagement fiable. 


13.2.3 PLANIFIER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES DE SORTIE 

13.2.3.1 PLAN D’ENGAGEMENT DES PARTIES PRENANTES 

Le plan d’engagement des parties prenantes est un element du plan de management du projet qui identifie les 
strategies et les actions requises pour encourager I’implication productive des parties prenantes dans la prise de 
decision et I'execution. II peut etre formel ou informel, tres detaille ou peu detaille, en fonction des besoins du projet et 
des attentes des parties prenantes. 

Le plan d'engagement des parties prenantes inclut notamment les strategies ou approches specifiques visant a 
mobiliser des personnes ou des groupes de parties prenantes. 
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13.3 GERER L’ENGAGEMENT DES PARTIES PRENANTES 


Gerer I'engagement des parties prenantes est le processus qui consiste a communiquer et a travailler avec les parties 
prenantes afin de satisfaire leurs besoins et leurs attentes, de gerer les points a traiter et de les encourager a participer 
de maniere adequate. L'interet principal de ce processus est qu’il permet au chef de projet d’accroTtre le support des 
parties prenantes et de minimiser leur resistance. Ce processus est execute tout au long du projet. Les donnees d’entree, 
les outils, les techniques et les donnees de sortie de ce processus sont presentes a la figure 13-7. La figure 13-8 
presente le diagramme de flux de donnees du processus. 
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Figure 13-7. Gerer I’engagement des parties prenantes: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 13-8. Gerer I’engagement des parties prenantes: diagramme de flux de donnees 


Gerer I'engagement des parties prenantes inclut des activites telles que : 

♦ I’implication des parties prenantes a des moments opportuns du projet en vue d’obtenir, de confirmer ou de 
maintenir la poursuite de leur engagement en faveur de la reussite du projet; 

♦ la gestion des attentes des parties prenantes grace a la negociation et a la communication ; 

♦ la prise en compte des risques ou preoccupations possibles lies a la gestion des parties prenantes et I'anticipation 
des futurs points a traiter pouvant etre souleves par les parties prenantes ; 

♦ la clarification et la resolution des points a traiter identifies. 

Ce processus permet de s’assurer que les parties prenantes ont bien compris les objectifs, les benefices et les 
risques du projet mais aussi de voir dans quelle mesure leur contribution accroTtra les chances de reussite du projet. 


524 


Premiere partie - Guide 



















































13.3.1 GERER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES D’ENTREE 


13.3.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
decrit les methodes, les formats et les technologies utilises pour la communication entre les parties prenantes. 

♦ Plan de gestion des risques. II est decrit a la section 11.1.3.1. Le plan de gestion des risques decrit les 
categories de risques, I’appetence au risque et les formats des rapports a utiliser pour gerer I’engagement des 
parties prenantes. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d'engagement des parties 
prenantes fournit les directives et les informations sur la gestion des attentes des parties prenantes. 

♦ Plan de gestion des changements. II est decrit a la section 4.2.3.1. Le plan de gestion des changements decrit 
le processus de soumission, devaluation et d’application des changements du projet. 

13.3.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Les demandes de changement et leur etat sont 
documents dans le journal des changements, puis communiques aux parties prenantes appropriees. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les preoccupations concernant le projet ou les parties 
prenantes sont consignees dans le journal des points a traiter, ainsi que les actions a executer pour leur gestion. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut du 
projet, relatifs a la gestion de I’engagement des parties prenantes, peuvent etre appliques aux phases ulterieures 
afin d'ameliorer I’efficacite de ce processus. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes fournit la 
liste des parties prenantes du projet et toute information necessaire a I'application du plan d’engagement des 
parties prenantes. 
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13.3.1.3 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus Gerer 
I’engagement des parties prenantes, on peut citer: 

♦ la culture de I'organisation, le climat politique et la structure de gouvernance de I'organisation ; 

♦ les politiques d’administration du personnel; 

♦ les seuils de risque des parties prenantes ; 

♦ les canaux de communication etablis ; 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 

13.3.1.4 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus Gerer I’engagement des parties 
prenantes, on peut citer: 

♦ les politiques et les procedures de I’organisation relatives aux reseaux sociaux, a la deontologie et a la securite; 

♦ les politiques et les procedures de I’organisation relatives aux points a traiter, aux risques, au changement et a 
la gestion des donnees ; 

♦ les exigences de I’organisation en matiere de communication ; 

♦ les directives standardises sur elaboration, I'echange, la conservation et la recuperation des informations; 

♦ les donnees historiques des projets anterieurs. 

13.3.2 GERER L’ENGAGEMENT DES PARTIES PRENANTES : OUTILS ET TECHNIQUES 
13.3.2.1 JUGEMENT A DIRE D’EXPERT 

II est decrit a la section 4.1.2.1. II convient de faire appel a la competence de personnes ou de groupes ayant une 
connaissance specialise ou une formation dans les domaines suivants : 

♦ politiques et structures du pouvoir de I'organisation et en dehors de I'organisation ; 

♦ environnement et culture de I’organisation et en dehors de I'organisation ; 

♦ techniques analytiques et devaluation a utiliser pour les processus d’engagement des parties prenantes ; 

♦ strategies et methodes de communication ; 

♦ caracteristiques des parties prenantes, des groupes de parties prenantes et des organisations impliques dans le 
projet actuel et susceptibles d’avoir participe a des projets anterieurs ; 

♦ gestion des exigences, des fournisseurs et des changements. 
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13.3.2.2 COMPETENCES EN COMMUNICATION 

Les methodes de communication, identifies pour chacune des parties prenantes dans le plan de gestion de 
la communication, sont appliquees au cours de la gestion de I'engagement des parties prenantes. L'equipe de 
management de projet s’appuie sur le retour d’information pour mieux comprendre les reactions des parties prenantes 
aux diverses activites et decisions cles du management de projet. II existe differentes fagons d’obtenir un retour 
d’information, notamment: 

♦ les conversations, tant formelles qu’informelles; 

♦ I’identification et la discussion des points a traiter; 

♦ les reunions; 

♦ les rapports d’avancement; 

♦ lesenquetes. 

13.3.2.3 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles et d’equipe pouvant etre utilisees pour ce processus figurent notamment 
les elements suivants: 

♦ Gestion des conflits. Elle est decrite a la section 9.5.2.1. Le chef de projet doit s’assurer que les conflits sont 
resolus rapidement. 

♦ Conscience culturelle. Elle est decrite a la section 10.1.2.6. La conscience culturelle aide le chef de projet et 
son equipe a communiquer efficacement en tenant compte des differences culturelles et des exigences des 
parties prenantes. 

♦ Negociation. Elle est decrite a la section 12.2.2.5. La negociation permet d’obtenir le support ou un accord qui 
appuie le travail du projet ou ses resultats mais aussi de resoudre les conflits au sein de l’equipe ou avec d’autres 
parties prenantes. 

♦ Observation et discussion. Elies sont decrites a la section 5.2.2.6. L’observation et la discussion permettent de 
rester au fait du jour avec le travail et I’attitude des membres de l’equipe projet et des autres parties prenantes. 

♦ Conscience politique. Elle est decrite a la section 10.1.2.6. La conscience politique se developpe avec la 
comprehension des relations de pouvoir au sein et autour du projet. 
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13.3.2.4 REGLES DE BASE 

Les regies de base, definies dans la charte d’equipe, decrivent le comportement attendu des membres de I’equipe 
projet et des autres parties prenantes, quant a leur engagement. 

13.3.2.5 REUNIONS 

Elies sont decrites a la section 10.1.2.8. Les reunions permettent d’aborder et de resoudre les points a traiter ou 
preoccupations concernant I’engagement des parties prenantes. Parmi les types de reunion benefiques dans le cadre 
de ce processus, figurent entre autres : 

♦ la prise de decision ; 

♦ la resolution des points a traiter; 

♦ les retours d’experience et les retrospectives ; 

♦ le lancement du projet; 

♦ la planification des Sprints; 

♦ les mises a jour du statut du projet. 

13.3.3 GERER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES DE SORTIE 

13.3.3.1 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. A la suite du processus Gerer I’engagement des parties prenantes, des 
changements apportes au perimetre du projet ou au contenu du produit peuvent apparartre. Toute demande de 
changement est passee en revue et traitee par le processus Maitriser les changements (voir la section 4.6). 
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13.3.3.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements 
de I’organisation par I’intermediaire d’une demande de changement. Parmi les composants du plan de management 
du projet qui peuvent exiger une demande de changement pour le plan de management du projet, on peut citer les 
elements suivants: 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
est mis a jour afin de refleter des exigences nouvelles ou modifiees des parties prenantes. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Le plan d’engagement des parties 
prenantes est mis a jour afin de refleter des strategies nouvelles ou modifiees de gestion et ainsi d’entretenir 
I'engagement des parties prenantes. 

13.3.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des changements. II est decrit a la section 4.6.3.3. Le journal des changements peut etre mis a jour en 
fonction d’une demande de changement. 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Le journal des points a traiter peut etre mis a jour 
afin de refleter une actualisation ou une saisie du journal. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Le registre des retours d’experience est mis 
a jour en ce qui concerne les approches efficaces ou non de gestion de ^engagement des parties prenantes afin 
que les informations puissent etre utilisees dans le cadre du projet actuel ou de prochains projets. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes peut 
etre mis a jour en fonction des nouvelles informations concernant les points a traiter resolus, les modifications 
approuvees, et I’etat general du projet. 
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13.4 MAITRISER L’ENGAGEMENT DES PARTIES PRENANTES 


MaTtriser I’engagement des parties prenantes est le processus qui consiste a suivre les relations avec les parties 
prenantes du projet et a adapter les strategies afin d’encourager leur engagement suite au changement des plans et des 
strategies d’engagement. L'interet principal de ce processus est qu’il permet de maintenir ou de renforcer I’efficience 
et I’efficacite des activites d'engagement des parties prenantes au fur et a mesure que le projet et son environnement 
evoluent. Ce processus est execute tout au long du projet. Les donnees d’entree, les outils, les techniques et les donnees 
de sortie de ce processus sont presentes a la figure 13-9. La figure 13-10 presente le diagramme de flux de donnees 
du processus. 
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Figure 13-9. Maitriser I’engagement des parties prenantes: donnees d’entree, outils, techniques et donnees de sortie 
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Figure 13-10. Maitriser I’engagement des parties prenantes: diagramme de flux de donnees 
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13.4.1 MATTRISER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES D’ENTREE 


13.4.1.1 PLAN DE MANAGEMENT DU PROJET 

II est decrit a la section 4.2.3.1. Les composants communs au plan de management du projet sont notamment 
les suivants: 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Le plan de gestion des ressources identifie les 
methodes de gestion des membres de I’equipe. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Le plan de gestion de la communication 
decrit les plans et les strategies de communication avec les parties prenantes du projet. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. II definit le plan de gestion des 
besoins et des attentes des parties prenantes. 

13.4.1.2 DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre considers comme des donnees d’entree pour ce processus 
figurent notamment les elements suivants: 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. II consigne tous les points a traiter connus lies au 
projet et aux parties prenantes. 

♦ Registre des retours d’experience. II est decrit a la section 4.4.3.1. Les retours d’experience du debut 
du projet peuvent etre appliques aux phases ulterieures afin d’ameliorer I'efficacite de I’engagement des 
parties prenantes. 

♦ Communications du projet. Elies sont decrites a la section 10.2.3.1. Sont comprises les communications du 
projet qui ont ete distributes aux parties prenantes comme le definissent le plan de gestion de la communication 
et le plan d’engagement des parties prenantes. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques contient les risques identifies 
pour le projet, notamment ceux lies a I'engagement et aux interactions des parties prenantes, leur categorisation 
et la liste des reponses eventuelles. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.3.1. Le registre des parties prenantes contient des 
informations qui permettent notamment d'identifier, d’evaluer et de classer les parties prenantes. 

13.4.1.3 DONNEES DE PERFORMANCE D’EXECUTION 

Elies sont decrites a la section 4.3.3.2. Les donnees de performance d’execution contiennent des informations sur 
I'etat du projet, comme les parties prenantes qui soutiennent le projet mais aussi leurs niveau ettype d’engagement. 
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13.4.1.4 FACTEURS ENVIRONNEMENTAUX DE [.’ORGANISATION 


Parmi les facteurs environnementaux de I’organisation qui peuvent avoir une influence sur le processus MaTtriser 
I’engagement des parties prenantes, on peut citer: 

♦ la culture de I'organisation, le climat politique et le cadre de gouvernance ; 

♦ les politiques d’administration du personnel; 

♦ les seuils de risque des parties prenantes ; 

♦ les canaux de communication etablis ; 

♦ les tendances, les pratiques ou les habitudes globales, regionales ou locales ; 

♦ la repartition geographique des installations et des ressources. 

13.4.1.5 ACTIFS ORGANISATIONNELS 

Parmi les actifs organisationnels qui peuvent avoir une influence sur le processus MaTtriser I’engagement des parties 
prenantes, on peut citer: 

♦ les politiques et les procedures de I’organisation relatives aux reseaux sociaux, a la deontologie et a la securite; 

♦ les politiques et les procedures de I’organisation relatives aux points a traiter, aux risques, au changement et a 
la gestion des donnees ; 

♦ les exigences de I’organisation en matiere de communication ; 

♦ les directives standardises sur elaboration, I'echange, la conservation et la recuperation des informations; 

♦ les donnees historiques des projets anterieurs. 

13.4.2 MAITRISER L’ENGAGEMENT DES PARTIES PRENANTES : OUTILS ET TECHNIQUES 
13.4.2.1 ANALYSE DES DONNEES 

Parmi les techniques d’analyse des donnees pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse des alternatives. Elle est decrite a la section 9.2.2.5. Une analyse des alternatives peut etre utilisee 
pour evaluer les options de reponse aux ecarts par rapport aux resultats souhaites de I'engagement des 
parties prenantes. 

♦ Analyse des causes originelles. Elle est decrite a la section 8.2.2.2. Une analyse des causes originelles 
peut etre utilisee pour determiner la raison sous-jacente fondamentale pour laquelle I’engagement des parties 
prenantes n’a pas I'effet prevu. 

♦ Analyse des parties prenantes. Elle est decrite a la section 13.1.2.3. L'analyse des parties prenantes contribue 
a determiner le positionnement des parties prenantes en tant que groupes et personnes a un moment donne 
du projet. 
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13.4.2.2 PRISE DE DECISION 

Parmi les techniques de prise de decision pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Analyse decisionnelle multicritere. Elle est decrite a la section 8.1.2.4. Les criteres d’un engagement fructueux 
des parties prenantes sont priorises et ponderes afin d’identifier le choix le plus approprie. 

♦ Vote. II est decrit a la section 5.2.2.4. Le vote permet de choisir la meilleure reponse a un ecart d'engagement 
des parties prenantes. 

13.4.2.3 REPRESENTATION DES DONNEES 

Parmi les techniques de representation des donnees utilisees pour ce processus figure notamment la matrice 
devaluation de I'engagement des parties prenantes. Elle est decrite a la section 13.2.2.3. Cette matrice permet de 
maTtriser I’engagement des parties prenantes grace au suivi des changements de leur niveau d’engagement. 

13.4.2.4 COMPETENCES EN COMMUNICATION 

Parmi les techniques de communication pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Retour ((’information. II est decrit a la section 10.2.2.3. Le retour d’information permet de s'assurer que les 
parties prenantes ont regu et compris les informations. 

♦ Presentations. Elies sont decrites a la section 10.2.2.3. Les presentations apportent des informations claires 
aux parties prenantes. 

13.4.2.5 COMPETENCES INTERPERSONNELLES ET D’EQUIPE 

Parmi les competences interpersonnelles pouvant etre utilisees pour ce processus figurent notamment les 
elements suivants: 

♦ Ecoute active. II est decrit a la section 10.2.2.6. L'ecoute active permet de limiter les problemes de comprehension 
et de communication. 

♦ Conscience culturelle. Elle est decrite a la section 10.1.2.6. La conscience culturelle aide le chef de projet a 
planifier les communications en se fondant sur les differences culturelles et les exigences des parties prenantes 
et des membres de I'equipe. 

♦ Leadership. II est decrit a la section 3.4.4. Un engagement reussi des parties prenantes necessite de solides 
competences de leadership pour communiquer la vision et inciter les parties prenantes a supporter le travail et 
les resultats du projet. 

♦ Networking. II est decrit a la section 10.2.2.6. Le networking garantit I’acces aux informations sur les niveaux 
d’engagement des parties prenantes. 

♦ Conscience politique. Elle est decrite a la section 10.1.2.6. La conscience politique consiste a comprendre les 
strategies de I'organisation, a savoir qui exerce le pouvoir et a de I'influence dans ce champ et a developper une 
aptitude a communiquer avec ces parties prenantes. 
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13.4.2.6 REUNIONS 


Les types de reunions incluent les reunions d'etat, les melees (scrum), les retrospectives ainsi que toute autre reunion 
convenue dans le plan d’engagement des parties prenantes afin de maTtriser et d’evaluer les niveaux d’engagement des 
parties prenantes. Les reunions ne sont plus limitees aux interactions en personne ou audio. Les reunions presentielles 
sont ideales, mais couteuses. Teleconference et technologie comblent I’ecart et fournissent de nombreuses fagons de 
se connecter et d’organiser une reunion. 


13.4.3 MAITRISER L’ENGAGEMENT DES PARTIES PRENANTES : DONNEES DE SORTIE 

13.4.3.1 INFORMATION SUR LA PERFORMANCE D’EXECUTION 

Elle est decrite a la section 4.5.1.3. L’information sur la performance d’execution inclut des donnees sur I'etat 
d’engagement des parties prenantes, comme le niveau de support actuel du projet par rapport aux niveaux souhaites 
d’engagement definis par la matrice correspondante, le cube des parties prenantes ou tout autre outil. 

13.4.3.2 DEMANDES DE CHANGEMENT 

Elies sont decrites a la section 4.3.3.4. Une demande de changement peut inclure des actions correctives et 
preventives visant a ameliorer le niveau actuel d’engagement des parties prenantes. Les demandes de changement 
sont passees en revue et traitees par le processus MaTtriser les changements (voir la section 4.6). 

13.4.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tout changement apporte au plan de management du projet est soumis au processus Gestion des changements de 
I’organisation par I’intermediaire d’une demande de changement. Parmi les composants du plan de management du 
projet qui peuvent exiger une demande de changement, on peut citer les elements suivants : 

♦ Plan de gestion des ressources. II est decrit a la section 9.1.3.1. Les responsabilites de I’equipe concernant les 
activites d’engagement des parties prenantes peuvent necessiter une mise a jour. 

♦ Plan de gestion de la communication. II est decrit a la section 10.1.3.1. Les strategies de communication du 
projet peuvent necessiter une mise a jour. 

♦ Plan d’engagement des parties prenantes. II est decrit a la section 13.2.3.1. Les informations sur la 
communaute des parties prenantes du projet peuvent necessiter une mise a jour. 
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13.4.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus, figurent 
notamment les elements suivants : 

♦ Journal des points a traiter. II est decrit a la section 4.3.3.3. Les informations contenues dans le journal des 
points a traiter indiquent les comportements des parties prenantes. Elies peuvent necessiter une mise a jour. 

♦ Registre des retours d’experience. II est decrit a la section 4.3.3.1. Le registre des retours d’experiences est 
mis a jour a I’aide des informations sur les difficulty rencontrees et la fagon dont elles auraient pu etre evitees. II 
est egalement mis a jour avec les approches qui ont permis de mobiliser les parties prenantes de fagon optimale, 
et celles qui n’ont pas bien fonctionne. 

♦ Registre des risques. II est decrit a la section 11.2.3.1. Le registre des risques peut necessiter une mise a jour 
afin d’inclure les reponses aux risques des parties prenantes. 

♦ Registre des parties prenantes. II est decrit a la section 13.1.12-13.1. Le registre des parties prenantes est mis 
a jour grace aux informations obtenues a la suite du processus MaTtriser I’engagement des parties prenantes. 
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Deuxieme partie 


Le Standard pour 
le Management de Projet 






INTRODUCTION 

Un standard est un document redige en fonction d’une autorite, d’un usage ou d’un consentement general afin de 
servir de modele ou d'exemple. Le present standard a ete elabore a I'aide d’un processus fonde sur les concepts de 
consensus, d’ouverture, de procedure officielle et d’equilibre. II decrit les processus considers comme des bonnes 
pratiques dans la majorite des projets, la plupart du temps. Ces processus sont repartis en groupes. En outre, le standard 
definit les principaux concepts du management de projet, y compris la relation entre le management de projet d’une 
part, et la strategie et les objectifs organisationnels, la gouvernance, le management de portefeuille et de programme, 
I’environnement de projet et la reussite du projet, d’autre part. II comprend egalement des informations sur les cycles de 
vie du projet, les parties prenantes et le role du chef de projet. La section 1 presente les principaux concepts et fournit 
des informations contextuelles sur le management de projet. Les sections 2 a 6 definissent chacun des cinq groupes de 
processus et decrivent les processus qu’ils contiennent. Elies detaillent egalement les principaux benefices, ainsi que 
les donnees d’entree et de sortie de chaque processus de management de projet. Ce standard sert de fondement et 
de cadre pour Un Guide du Corpus des connaissances en management de projet (PMBOK® Guide)\ Le Guide PMBOK® 
developpe les informations contenues dans ce standard en presentant une description plus detaillee du contexte, de 
I’environnement et des influences sur le management de projet. Par ailleurs, le Guide PMBOK® decrit les donnees 
d’entree et de sortie des processus de management de projet, recense les outils et les techniques et examine les 
principaux concepts et les tendances emergentes associes a chaque domaine de connaissance. 


Project Management Institute. 2017, Guide du Corpus des connaissances en management de projet (Guide PMBOK®) 
Newton Square, PA: auteur. 
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1.1 PROJETS ET MANAGEMENT DE PROJET 


Un projet est une initiative temporaire entreprise dans le but de creer un produit, un service ou un resultat unique. 
La nature temporaire des projets implique un debut et une fin clairement definis. Le fait qu’un projet soit temporaire ne 
signifie pas necessairement qu’il est de courte duree. La fin d’un projet est atteinte lorsque les objectifs ont ete satisfaits, 
ou lorsque le projet est arrete parce que ses objectifs ne seront pas ou ne pourront pas etre atteints, ou lorsque le projet 
n’est plus utile. La decision d'arreter un projet doit etre approuvee et autorisee par une autorite competente. 

Le management de projet est I'application de connaissances, de competences, d’outils et de techniques aux activites 
d’un projet afin d’en satisfaire les exigences. Le management de projet est effectue en appliquant et en integrant, 
de maniere appropriee, les processus de management de projet identifies pour le projet. 

Le management d’un projet consiste, habituellement et de maniere non exhaustive, a: 

♦ recenser les exigences du projet; 

♦ repondre aux differents besoins, preoccupations et attentes des parties prenantes ; 

♦ etablir et entretenir une communication active avec les parties prenantes; 

♦ gerer les ressources ; 

♦ maintenir un equilibre entre les contraintes du projet, qui sont en concurrence et qui concernent, entre autres : 

■ le perimetre, 

■ I’echeancier, 

■ le cout, 

■ la qualite, 

■ les ressources, 

■ les risques. 

Les circonstances du projet influeront sur la fagon dont chaque processus de management de projet est applique 
et sur la hierarchisation des contraintes du projet. 
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1.2 RELATIONS ENTRE PORTEFEUILLES, PROGRAMMES ET PROJETS 


Un portefeuille designe des projets, des programmes, des portefeuilles secondaires et des operations, geres de 
maniere coordonnee groupe, afin d’atteindre des objectifs strategiques. Le management de portefeuille designe le 
management centralise d’un ou de plusieurs portefeuilles afin d’atteindre des objectifs strategiques. Le management 
de portefeuille vise a s'assurer que le portefeuille est execute conformement aux objectifs de I’organisation et a evaluer 
les composants du portefeuille afin d’optimiser I’affectation des ressources. Les portefeuilles peuvent inclure des taches 
qui sont operationnelles par nature. 

Un programme designe des projets, des programmes secondaires et des activites de programme apparentes dont 
la gestion est coordonnee afin d’obtenir des benefices qui ne seraient pas possibles en les traitant isolement. Les 
programmes comportent des taches apparentees, en dehors du perimetre de chaque projet du programme. 
Le management de programme designe I’utilisation des connaissances, des competences et des principes necessaires 
a I’atteinte des objectifs du programme et a I’obtention de benefices et d’une maitrise qui vont au-dela d’un management 
individuel des composants du programme. Les programmes peuvent inclure des taches qui sont operationnelles 
par nature. 

Le management de programme contribue a I’execution des strategies organisationnelles en autorisant, changeant 
ou arretant les projets et en gerant leurs interdependances. La gestion des interdependences entre les projets peut 
inclure, entre autres, les actions suivantes: 

♦ la resolution des contraintes relatives aux ressources et/ou des conflits qui affectent plusieurs composants 
du programme; 

♦ I’harmonisation avec les strategies de I’organisation qui peuvent avoir des consequences sur les objectifs 
du programme; 

♦ la gestion des points a traiter et I’utilisation de la gestion des changements au sein d’une structure de 
gouvernance partagee; 

♦ la gestion des risques du programme et du projet qui peuvent influer sur un ou plusieurs composants; 

♦ la gestion de la realisation des benefices du programme en analysant, sequengant et suivant de maniere 
efficace les interdependances entre les composants. 

Un projet peut etre manage selon trois scenarii distincts, a savoir en tant que projet independant (en dehors d’un 
portefeuille ou d’un programme), au sein d’un programme ou au sein d’un portefeuille. Lorsqu’un projet est manage 
au sein d’un portefeuille ou d’un programme, le management de projet entre en interaction avec le management de 
programme et le management de portefeuille. 
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La figure 1-1 illustre un modele de structure de portefeuille indiquant les liens entre les composants, les ressources 
partagees et les parties prenantes. Les composants d’un portefeuille sont regroupes afin de faciliter la bonne 
gouvernance et la gestion efficace du travail, et de mettre en oeuvre les strategies et les priorites de I’organisation. Grace 
a une hierarchisation fondee sur le risque, le financement et d'autres considerations, la planification de I’organisation 
et du portefeuille influe sur les composants. Ainsi, les organisations peuvent avoir un apergu de la fagon dont les 
objectifs strategies ressortent dans le portefeuille, instaurer une gouvernance de portefeuille, de programme et de 
projet appropriee et autoriser I’utilisation des ressources humaines, financiers ou physiques. Ces ressources seront 
distributes en fonction des benefices et des resultats attendus. Comme le montre la figure 1-1, les strategies et 
les priorites organisationnelles sont liees et instituent des relations entre les portefeuilles et les programmes, entre 
les portefeuilles et les projets et entre les programmes et les projets individuels. Ces relations ne sont pas toujours 
strictement hierarchies. 

Le management de projet organisationnel (OPM ou Organizational Project Management) est un cadre d’execution 
de strategies utilisant le management de portefeuille, de programme et de projet. II offre un cadre qui permet aux 
organisations d’executer leur strategie organisationnelle de maniere coherente et previsible, en fournissant une 
performance optimisee, de meilleurs resultats et un avantage concurrentiel durable. 


Strategie organisationnelle 

t 



Figure 1 -1. Exemple d’interfaces entre management de portefeuille, de programme et de projet 
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1.3 RELATION ENTRE GOUVERNANCE ORGANISATIONNELLE 
ET GOUVERNANCE DU PROJET 


II existe differents types de gouvernance, y compris la gouvernance organisationnelle, la gouvernance du management 
de projet organisationnel et la gouvernance de portefeuille, de programme et de projet. La gouvernance organisationnelle 
est un moyen structure d’apporter une orientation et une martrise grace a des politiques et des processus, en vue 
d’atteindre des objectifs strategies et operationnels. La gouvernance organisationnelle est generalement assuree 
par un conseil d’administration, afin de garantir responsabilite, equite et transparence a regard des parties prenantes. 
Les principes, les decisions et les processus de la gouvernance organisationnelle peuvent avoir des consequences sur 
la gouvernance des portefeuilles, des programmes et des projets de la maniere suivante: 

♦ en faisant respecter les contraintes juridiques, reglementaires, de conformite et les standards ; 

♦ en definissant les responsabilites ethiques, sociales et environnementales; 

♦ en indiquant les politiques a suivre en matiere operationnelle, juridique et de risque. 

La gouvernance du projet comprend le cadre, les fonctions et les processus qui guident les activites de management 
de projet afin de developper un service, un produit ou un resultat unique permettant d’atteindre des objectifs 
organisationnels, strategies et operationnels. La gouvernance au niveau du projet implique: 

♦ d’orienter et de superviser la gestion des taches du projet; 

♦ de faire respecter les politiques, standards et directives ; 

♦ d’etablir les roles, responsabilites et pouvoirs en matiere de gouvernance ; 

♦ de prendre des decisions en ce qui concerne I'escalade des risques, les changements et les ressources 
(c’est a-dire I’equipe, les finances, les infrastructures); 

♦ de garantir le bon engagement des parties prenantes; 

♦ de suivre la performance. 

Le cadre de la gouvernance du projet fournit aux parties prenantes du projet une structure, des processus, des 
roles, des responsabilites et des modeles de prise de decision pour le management du projet. Parmi les elements qui le 
composent on peut citer, entre autres, les principes ou les processus pour: 

♦ les revues de passage d’etape ou de phase ; 

♦ I’identification, la transmission et la resolution des risques et des points a traiter; 

♦ la definition des roles, des responsabilites et des pouvoirs ; 

♦ la gestion des connaissances du projet et I’enregistrement des retours d’experience ; 

♦ la prise de decisions, la resolution de problemes et la transmission des sujets qui depassent I’autorite du 
chef de projet; 

♦ la revue et I'approbation des changements apportes au projet et aux produits qui depassent I'autorite du 
chef de projet. 
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1.4 REUSSITE DU PROJET ET GESTION DES BENEFICES 


Les projets sont entrepris afin de saisir des opportunites commerciales conformes aux objectifs strategiques de 
I’organisation. Avant d’entreprendre un projet, on elabore souvent un business case destine a presenter les objectifs du 
projet, I’investissement necessaire ainsi que les criteres financiers et qualitatifs de la reussite du projet. Le business 
case sert de base pour mesurer la reussite et I'avancement tout au long du cycle de vie du projet en comparant les 
resultats avec les objectifs et les criteres de reussite recenses. 

Les projets sont habituellement lances a la suite d’une ou de plusieurs des considerations strategiques suivantes : 

♦ demande du marche; 

♦ opportunity strategique/besoin commercial; 

♦ besoin social; 

♦ consideration environnementale; 

♦ demande client; 

♦ progres technologique; 

♦ contrainte juridique ou reglementaire; 

♦ probleme existant ou anticipe. 

Un plan de gestion des benefices decrit comment et quand le projet offrira des benefices et comment ils seront 
mesures. II peut comprendre les elements suivants: 

♦ les benefices attendus ; la valeur commerciale tangible et intangible qui doit etre obtenue grace a I'application 
du produit, du service ou du resultat; 

♦ I’alignement strategique ; la fagon dont les benefices du projet soutiennent et suivent les strategies de 
I'organisation; 

♦ le delai d’obtention des benefices ; les benefices par phase : court terme, long terme et en continu ; 

♦ le charge de benefice ; la personne ou le groupe charge de suivre, d’enregistrer et de rendre compte des 
benefices obtenus dans le delai etabli dans le plan ; 

♦ les mefriques ; les mesures directes et indirectes utilisees pour montrer les benefices obtenus ; 

♦ les risques ; les risques associes a I’obtention des benefices attendus. 
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La reussite du projet est mesuree par rapport aux objectifs du projet et aux criteres de reussite. Dans de nombreux 
cas, le succes du produit, du service ou du resultat n’est connu qu’un certain temps apres la fin du projet. On 
peut ne pas etre au fait, par exemple, d’une augmentation de parts de marche, d’une reduction des depenses 
d’exploitation ou du succes d’un nouveau produit lorsque le projet passe a la phase operationnelle. Dans ce cas, le 
bureau des projets (Project Management Office, PMO), le comite de pilotage du portefeuille ou une autre fonction 
au sein de I'organisation devra evaluer la reussite ulterieurement afin de determiner si les resultats ont satisfait les 
objectifs de I'organisation. 

Le business case et le plan de gestion des benefices sont tous les deux elabores avant le lancement du projet. 
En outre, ces deux documents sont references apres la fin du projet. Par consequent, ils sont plutot considers comme 
des documents business et non comme des documents de projet ou des composants du plan de management du projet. 
Le cas echeant, ces documents business peuvent constituer des donnees d’entree pour certains processus utilises dans 
le management du projet, comme la redaction de la charte du projet. 


1.5 CYCLE DE VIE DU PROJET 

Le cycle de vie d’un projet est la serie de phases que celui-ci traverse, depuis son initialisation jusqu'a sa cloture. 
Une phase de projet est un ensemble d’activites du projet liees logiquement qui aboutit a la realisation d’un ou de 
plusieurs livrables. Les phases peuvent etre sequentielles, iteratives ou parallels. Leur nom, leur nombre et leur duree 
sont determines par les besoins de management et de martrise de I’organisation ou des organisations qui prennent 
part au projet, ainsi que par la nature du projet lui-meme et par son domaine d'application. Les phases sont assorties 
de delais, avec un point de depart et une echeance ou un point de maitrise (parfois denomme revue de phase, phase 
gate, passage de controle ou autre). Au niveau du point de martrise, la charte du projet et les documents business 
sont reexamines sur la base de I'environnement actuel. A ce stade, la performance du projet est comparee au plan de 
management du projet afin de determiner si le projet devrait etre change, arrete ou poursuivi comme prevu. 
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Le cycle de vie du projet peut etre influence par les aspects uniques de I’organisation, de I'industrie, de la methode 
de developpement ou de la technology mise en oeuvre. Si tout projet a un debut et une fin, les livrables et le travail 
specifique qui sont executes varient tres largement en fonction du projet. Quel que soit le travail particular concerne, le 
cycle de vie du projet fournit un cadre de reference pour manager le projet. 

Malgre la difference de taille et de complexity entre les projets, il est possible de schematiser un projet type selon la 
structure de cycle de vie du projet suivante (voir figure 1 -2): 

♦ initialisation du projet; 

♦ organisation et preparation ; 

♦ execution du travail; 

♦ cloture du projet. 


Cycle de vie du projet 



Figure 1-2. Representation generique du cycle de vie d’un projet 
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La structure generique du cycle de vie presente generalement les caracteristiques suivantes: 

♦ En debut de projet, le niveau des couts etdes ressources humaines estfaible; il augmente au cours de I’execution 
du projet et diminue rapidement a mesure que le projet approche de son terme. 

♦ Le risque est plus grand au debut du projet, comme illustre a la figure 1-3. L’effet de ces facteurs diminue au 
cours du cycle de vie du projet au fur et a mesure que des decisions sont prises et que les livrables sont acceptes. 

♦ Sans avoir d’impact significatif sur les couts et I’echeancier, la capacite des parties prenantes a influer sur les 
caracteristiques finales du produit du projet est plus forte en debut de projet et diminue au fur et a mesure que 
le projet approche de son terme. La figure 1-3 illustre la croissance, generalement importante, du cout des 
changements et de la correction des erreurs, lorsque le projet approche de son terme. 



Figure 1-3. Impact des variables au fil du temps 
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1.6 PARTIES PRENANTES DU PROJET 


Une partie prenante est une personne, un groupe ou un organisme qui peut influer sur, etre influence par, ou se 
considerer comme influence par une decision, une activite ou le resultat d’un projet. Les parties prenantes du projet 
peuvent etre internes ou externes au projet. Elies peuvent etre activement impliquees, passivement impliquees ou 
ignorer le projet. Les parties prenantes peuvent avoir un impact positif ou negatif sur le projet, ou inversement. Parmi 
tous les exemples de parties prenantes, on peut citer: 

♦ Les parties prenantes internes: 

■ le sponsor; 

■ le gestionnaire des ressources ; 

■ le bureau des projets (Project Management Office, PMO); 

■ le comite de pilotage du portefeuille ; 

■ le chef de programme; 

■ les chefs de projet d’autres projets ; 

■ les membres de I’equipe. 

♦ Les parties prenantes externes : 

■ les clients; 

■ les utilisateursfinaux; 

■ les fournisseurs; 

■ les actionnaires; 

■ les organes de regimentation ; 

■ les concurrents. 
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Equipe projet 
Chefs PPP 
Gestionnaires des ressources 


Parties prenantes 
Fournisseurs 
Clients 

Utilisateurs finaux 


Sponsors 

Instances dirigeantes 
Comites de direction 
Bureaux des projets 


Figure 1-4 Exemples de parties prenantes d’un projet. 


La figure 1-4 donne des exemples de parties prenantes d’un projet. La participation des parties prenantes peutaller 
de contributions occasionnelles a des enquetes et a des groupes de discussion jusqu’a sponsoriser completement un 
projet avec soutien financier, politique ou autre. Le type et le niveau de cette participation au projet peuvent changer au 
cours du cycle de vie du projet. Par consequent, pour la reussite du projet, il est indispensable d'identifier, d’analyser et 
d’engager les parties prenantes mais aussi de bien gerer leurs attentes dans le cadre du projet et leur participation tout 
au long du cycle de vie du projet. 
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1.7 ROLE DU CHEF DE PROJET 


Le chef de projet est la personne designee par I’organisation realisatrice pour diriger I’equipe chargee de la realisation 
des objectifs du projet. Les liens hierarchiques du chef de projet dependent de la structure de I'organisation et de la 
gouvernance du projet. 

Outre les competences techniques specifiques et les competences de management generates requises pour le projet, 
les chefs de projet doivent posseder au moins les attributs suivants: 

♦ la connaissance du management de projet, de I'environnement organisationnel, des aspects techniques et des 
autres informations necessaires pour bien manager le projet; 

♦ les competences necessaires pour diriger I’equipe projet de maniere efficace, coordonner le travail, collaborer 
avec les parties prenantes, resoudre les problemes et prendre des decisions; 

♦ les capacites pour developper et gerer le perimetre, les echeanciers, les budgets, les ressources, les risques, 
les plans, les presentations et les rapports ; 

♦ les autres attributs necessaires pour bien manager le projet, comme la personnalite, I'attitude, I’ethique et 
le leadership. 

Les chefs de projet accomplissent le travail avec les membres de I’equipe projet et les autres parties prenantes. 
Ms s'appuient sur d'importantes competences interpersonnelles, parmi lesquelles : 

♦ le leadership; 

♦ le developpement de I’esprit d’equipe; 

♦ la motivation; 

♦ la communication; 

♦ I’influence; 

♦ la prise de decision ; 

♦ la conscience politique et culturelle; 

♦ la negotiation; 

♦ la mediation; 

♦ la gestion des conflits ; 

♦ I'accompagnement. 

Le chef de projet a reussi sa mission lorsque les objectifs du projet ont ete atteints. Un autre aspect de la reussite 
reside dans la satisfaction des parties prenantes. Pour satisfaire les parties prenantes concernees, le chef de projet 
doit repondre a leurs besoins, a leurs preoccupations et a leurs attentes. Pour reussir, le chef de projet doit adapter 
I’approche du projet, le cycle de vie et les processus de management de projet afin de satisfaire aux exigences du projet 
et du produit. 
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1.8 DOMAINES DE CONNAISSANCE EN MANAGEMENT DE PROJET 


Les domaines de connaissance en management de projet sont des secteurs ou des domaines de specialisation 
communement utilises en management de projet. Un domaine de connaissance est un ensemble de processus associes 
a un theme particulier du management de projet. Ces 10 domaines de connaissance sont utilises pour la majorite des 
projets, la plupart du temps. Les besoins d’un projet specifique peuvent necessiter des domaines de connaissance 
supplementaires. Les 10 domaines de connaissance sont les suivants : 

♦ Gestion de (’integration du projet. La gestion de (’integration du projet inclut les processus et les activites qui 
identifient, definissent, combinent, unifient et coordonnent les differents processus et activites de management 
de projet au sein des groupes de processus de management du projet. 

♦ Gestion du perimetre du projet. La gestion du perimetre du projet comprend les processus permettant d’assurer 
que tout le travail requis par le projet, et seulement le travail requis, est effectue pour mener a bien le projet. 

♦ Gestion de I’echeancier du projet. La gestion de I'echeancier du projet inclut les processus permettant de gerer 
I’achevement du projet dans le temps voulu. 

♦ Gestion des couts du projet. La gestion des couts du projet inclut les processus relatifs a la planification des 
couts, a I’estimation, a I’etablissement du budget, au financement, au provisionnement, a la gestion et a la 
maTtrise des couts, de fagon a ce que le projet soit acheve dans les limites du budget approuve. 

♦ Gestion de la qualite du projet. La gestion de la qualite du projet inclut les processus de prise en compte de la 
politique qualite de I'organisation en ce qui concerne la planification, la gestion et la maTtrise des exigences de 
qualite du produit et du projet afin de satisfaire aux attentes des parties prenantes. 

♦ Gestion des ressources du projet. La gestion des ressources du projet inclut les processus qui consistent a 
identifier, obtenir et gerer les ressources requises pour garantir I’achevement du projet. 

♦ Gestion des communications du projet. La gestion des communications du projet inclut les processus requis 
pour assurer, de maniere appropriee et en temps utile, la planification, la collecte, la creation, la distribution, la 
conservation, la recherche, la gestion, la maTtrise et I’archivage final des informations du projet. 

♦ Gestion des risques du projet. La gestion des risques du projet inclut les processus de planification de la 
gestion des risques, d’identification, d’analyse, de planification des reponses, ainsi que d’execution des reponses 
aux risques et de maTtrise des risques dans le cadre d’un projet. 

♦ Gestion des approvisionnements du projet. La gestion des approvisionnements du projet inclut les processus 
d’achat ou d’acquisition des produits, des services ou des resultats necessaires et externes a I’equipe projet. 

♦ Gestion des parties prenantes du projet. La gestion des parties prenantes du projet inclut les processus 
necessaires pour identifier les personnes, les groupes ou les organisations susceptibles d’affecter le projet ou 
d’etre affectes par celui-ci, pour analyser les attentes des parties prenantes et leur impact sur le projet, mais 
aussi pour developper des strategies de gestion appropriees afin de mobiliser efficacement les parties prenantes 
en les impliquant dans les decisions du projet et son execution. 
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1.9 GROUPES DE PROCESSUS DE MANAGEMENT DE PROJET 


Le present standard decrit les processus de management de projet utilises pour atteindre les objectifs du projet. 
Les processus de management de projet sont repartis en cinq groupes de processus : 

♦ Groupe de processus d’initialisation. Processus permettent de definir un nouveau projet, ou une nouvelle 
phase d’un projet existant, par I'obtention de I’autorisation de demarrer ce nouveau projet ou cette nouvelle 
phase. Les processus d'initialisation sont decrits a la section 2. 

♦ Groupe de processus de planification. Processus permettent d'elaborer le perimetre du projet, d’affiner les 
objectifs et de definir la suite des actions necessaires a I'atteinte des objectifs pour lesquels le projet a ete 
entrepris. Les processus de planification sont decrits a la section 3. 

♦ Groupe de processus d’execution. Processus permettant de realiser le travail defini dans le plan de management 
du projet afin de satisfaire aux exigences du projet. Les processus d’execution sont decrits a la section 4. 

♦ Groupe de processus de maitrise. Processus permettent de suivre, de passer en revue et de reguler I’avancement 
et la performance du projet, d’identifier les endroits ou des changements du plan s'avereraient necessaires, et 
d’entreprendre les changements correspondants. Les processus de maitrise sont decrits a la section 5. 

♦ Groupe de processus de cloture. Processus permettant de realiser ou de clore formellement un projet, une 
phase ou un contrat. Les processus de cloture sont decrits a la section 6. 

Ces cinq groupes de processus sont independants des domaines d’application (comme le marketing, les services 
d’information ou la comptabilite) ou de I’orientation industrielle (construction, aerospatiale, telecommunications). 
Les processus individuels des groupes de processus sont souvent reiteres avant I'achevement d’une phase ou d’un 
projet. Le nombre d'iterations de processus et d’interactions entre les processus varie en fonction des besoins du projet. 
Generalement, les processus entrent dans I’une de ces trois categories : 

4 Processus utilises une fois ou a des moments predefinis dans le cadre du projet. II peut s'agit de rediger la 
charte du projet et de clore le projet ou la phase en cours. 

♦ Processus executes periodiquement. L’obtention de ressources est executee lorsque des ressources sont 
necessaires. II sera precede aux approvisionnements avant d’avoir besoin de I’article fourni. 

4 Processus realises en continu tout au long du projet. II est possible de definir les activites tout au long du 
cycle de vie du projet, en particulier lorsque le projet utilise une planification en vagues ou une approche de 
developpement adaptee. De nombreux processus de maitrise sont utilises en continu des le debut du projet, 
jusqu’a sa cloture. 
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Les donnees de sortie d’un processus sont en general des donnees d’entree d’un autre processus ou encore des 
livrables du projet ou d’une phase du projet. Par exemple, le plan de management du projet et les documents du projet 
(registre des risques, matrice des responsabilites, etc.) produits dans le groupe de processus de planification sont 
fournis au groupe de processus d’execution en cas de mises a jour. La figure 1-4 montre comment des groupes de 
processus peuvent se recouper au cours d’un projet ou d’une phase. 

Les groupes de processus ne sont pas des phases du projet. Lorsque le projet est divise en phases, les processus 
contenus dans les groupes de processus interagissent au sein de chacune des phases. Tous les processus de groupe 
peuvent etre represents au sein d’une phase, comme illustre a la figure 1-5. Les projets etant divises en phases 
distinctes, comme I’elaboration du concept, I’etude de faisabilite, la conception, le prototype, la fabrication ou encore 
les essais, les processus de chacun des groupes sont repetes autant que necessaire dans chaque phase jusqu’a ce que 
cette derniere ait satisfait a tous les criteres d’achevement. 


Niveau 

d’effort 


Groupe 

Groupe 

Groupe 

Groupe 

Groupe 

de processus 

de processus 

de processus 

de processus 

de processus 

d’initialisation 

de planification 

d'execution 

de maTtrise 

de cloture 



Debut 


Temps 


Fin 


Figure 1-5. Exemple d’interactions entre les groupes de processus au sein d’un projet ou d’une phase 


Le tableau 1 -1 liste les 49 processus qui correspondent aux groupes de processus et aux domaines de connaissance. 


555 












Tableau 1-1. Correspondance entre les groupes de processus de management de projet et les domaines de connaissance 




Groupes de processus de management de projet 

> 

Domaines 
de connaissance 

Groupe 
de processus 
d’initialisation 

Groupe 
de processus 
de planification 

Groupe 
de processus 
d’execution 

Groupe 
de processus 
de maTtrise 

Groupe 
de processus 
de cloture 

4. Gestion 

de I'integration 
du projet 

4.1 Elaborer 
la charte du projet 

4.2 Elaborer le plan 
de management 
du projet 

4.3 Diriger et gerer 
le travail du projet 

4.4 Gerer 

les connaissances 
du projet 

4.5 MaTtriser 
le projet 

4.6 MaTtriser 
les changements 

4.7 Clore le projet 
ou la phase 

5. Gestion 
du perimetre 
du projet 


5.1 Planifier 
la gestion 

du perimetre et 
du contenu 

5.2 Recueillir 
les exigences 

5.3 Definir 
le perimetre 

5.4 Creer le WBS 


5.5 Valider 
le perimetre 

5.6 MaTtriser 
le perimetre et 
le contenu 


6. Gestion 

de I’echeancier 
du projet 


6.1 Planifier 
la gestion 

de I’echeancier 

6.2 Definir 
les activites 

6.3 Organiser 
les activites 
en sequence 

6.4 Estimer 
la duree 
des activites 

6.5 Elaborer 
I’echeancier 


6.6 MaTtriser 
I’echeancier 


7. Gestion 
des couts 
du projet 


7.1 Planifier 
la gestion 
des couts 

7.2 Estimer 
les couts 

7.3 Determiner 
le budget 


7.4 MaTtriser 
les couts 


8. Gestion de 
la qualite 
du projet 


8.1 Planifier 
la gestion de 
la qualite 

8.2 Gerer la qualite 

8.3 MaTtriser 
la qualite 


9. Gestion 

des ressources 
du projet 


9.1 Planifier 
la gestion 

des ressources 

9.2 Estimer 
les ressources 
necessaires 
aux activites 

9.3 Obtenir 
les ressources 

9.4 Developper 
I’equipe 

9.5 Gerer I’equipe 

9.6 MaTtriser 
les ressources 


10. Gestion des 
communications 
du projet 


10.1 Planifier 
la gestion 
des communica¬ 
tions 

10.2 Gerer 
les communica¬ 
tions 

10.3 MaTtriser 
les communica¬ 
tions 


11. Gestion 
des risques 
du projet 


11.1 Planifier 
la gestion 
des risques 

11.2 Identifier 
les risques 

11.3 Mettre en 
ceuvre I’analyse 
qualitative 

des risques 

11.4 Mettre en 
ceuvre I’analyse 
quantitative 
des risques 

11.5 Planifier 
les reponses 
aux risques 

11.6 Appliquer 
les reponses 
aux risques 

11.7 MaTtriser 
les risques 


12. Gestion des 
approvisionnements 
du projet 


12.1 Planifier 
la gestion 
des approvision¬ 
nements 

12.2 Proceder 
aux approvision¬ 
nements 

12.3 MaTtriser 
les approvisionne¬ 
ments 


13. Gestion 
des parties 
prenantes 
du projet 

13.1 Identifier 
les parties 
prenantes 

13.2 Planifier 
I’engagement 
des parties 
prenantes 

13.3 Gerer 
I’engagement 
des parties 
prenantes 

13.4 MaTtriser 

1’engagement 
des parties 
prenantes 
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1.10 FACTEURS ENVIRONNEMENTAUX DE (.’ORGANISATION 
ET ACTIFS ORGANISATIONNELS 


Les projets existent et se deroulent dans des environnements qui peuvent les influencer. Ces influences peuvent 
avoir un impact favorable ou defavorable sur le projet. Parmi elles, deux grandes categories sont les facteurs 
environnementaux de I’organisation et les actifs organisationnels. 

Les facteurs environnementaux de I’organisation proviennent de I’environnement exterieur au projet et souvent de 
I’exterieur de I’organisation. Ces facteurs designent les conditions qui ne sont pas sous le controle immediat de I’equipe 
projet et qui influencent, contraignent ou impactent le projet. Ms peuvent avoir un impact au niveau de I’organisation, 
du portefeuille, du programme ou du projet. (Pour en savoir plus sur les facteurs environnementaux de I’organisation, 
voir la section 2.2 du Guide PMBOK®.) La culture, la structure et la gouvernance internes de I’organisation constituent 
un ensemble de ces facteurs. Elles incluent, par exemple, la vision, la mission, les valeurs, les croyances, les normes 
culturelles, la hierarchie et les relations de pouvoir. 

Les actifs organisationnels sont internes a I’organisation. Ms peuvent provenir de I’organisation elle-meme, d’un 
portefeuille, d’un programme, d’un autre projet ou d’une combinaison de ces elements. Les actifs organisationnels 
comprennent les plans, les processus, les politiques internes, les procedures et les bases de connaissances qui sont 
specifiques et utilises par I’organisation executante. Ces actifs influent sur le management de projet. II peut s'agir, par 
exemple, des procedures de martrise des changements, des modeles, des informations tirees de projets anterieurs 
et des archives des retours d’experience. (Pour en savoir plus sur les actifs organisationnels de I’organisation, voir 
la section 2.3 du Guide PMBOK®.) 
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1.11 ADAPTATION DES ELEMENTS DU PRO JET 


Dans ce contexte, le terme« element» designe les processus de management de projet, les donnees d’entree, les 
outils, les techniques, les donnees de sortie, les facteurs environnementaux de I’organisation et les actifs organisationnels. 
Le chef de projet et I'equipe de management de projet selectionnent et amenagent les elements appropries qu’ils vont 
utiliser dans le cadre de leur projet specifique. Cette activite de selection et d’amenagement est connue sous le nom 
d’adaptation. L’adaptation est necessaire, car chaque projet est unique et, par consequent, ne necessite pas chaque 
processus, donnee d’entree, outil, technique ou donnee de sortie. 

Le plan de management du projet est I’element le plus courant. II comprend de nombreux composants, comme les 
plans de management subsidiaires, les references de base et une description du cycle de vie du projet. Les plans de 
management subsidiaires sont les plans associes a un aspect specifique ou un domaine de connaissance du projet, 
comme un plan de gestion de I’echeancier, un plan de gestion des risques ou un plan de gestion des changements. 
L'adaptation consiste, en partie, a identifier les composants du plan de management du projet requis pour un projet 
particulier. Le plan de management du projet est une donnee d’entree et les mises a jour de ce plan constituent des 
donnees de sortie de nombreux processus de ce standard. Au lieu d’enumerer les composants d’un plan de management 
du projet individuel dans les tableaux de donnees d’entree/donnees de sortie, des exemples de composants susceptibles 
de constituer des donnees d'entree ou susceptibles d’etre mis a jour pour constituer des donnees de sortie sont 
listes sous les tableaux de donnees d’entree/donnees de sortie pour chaque processus. Les eventuels composants 
sont listes a titre d’exemple uniquement. Ces donnees d’entree et de sortie ne sont pas requises et ne sont pas les 
seules donnees d’entree ou mises a jour du plan de management du projet qu’un chef de projet peut utiliser dans ce 
processus particulier. 

Le plan de management du projet est I’un des principaux elements du projet, mais il existe d’autres documents qui ne 
font pas partie de ce plan et sont utilises pour manager le projet. Ces autres documents sont des documents de projet. 
Semblables aux composants du plan de management du projet, les documents necessaires a un processus dependront 
du projet individuel. Le chef de projet est charge d’identifier les documents necessaires a un processus et les documents 
de projet qui seront mis a jour et considers comme des donnees de sortie d’un processus. Les documents de projet 
listes sous les tableaux des donnees d'entree/donnees de sortie dans I'ensemble de ce standard sont des exemples 
possibles de documents de projet et ne constituent en aucun cas une liste exhaustive. 

Le tableau 1 -2 donne une liste representative des composants du plan de management du projet et des documents 
du projet. Cette liste n’est pas complete, mais elle represente bien les types de documents souvent utilises pour aider 
a manager un projet. 
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Tableau 1-2. Plan de management du projet et documents du projet 


Plan de management du projet 

Documents du projet 

1. Plan de gestion du perimetre 

1. Attributs des activites 

19. Mesures de controle de la qualite 

2. Plan de gestion des exigences 

2. Liste d’activites 

20. Metriques qualite 

3. Plan de gestion de I’echeancier 

3. Journal des hypotheses 

21. Rapport de qualite 

4. Plan de gestion des couts 

4. Base des estimations 

22. Documentation des exigences 

5. Plan de gestion de la qualite 

5. Journal des changements 

23. Matrice de tragabilite des exigences 

6. Plan de gestion des ressources 

6. Estimations de couts 

24. Organigramme des ressources 

7. Plan de gestion de la communication 

7. Previsions de couts 

25. Calendriers des ressources 

8. Plan de gestion des risques 

8. Estimations de durees 

26. Besoins en ressources 

9. Plan de gestion des approvisionnements 

9. Journal des points a traiter 

27. Registre des risques 

10. Plan d’engagement des parties prenantes 

10. Registre des retours d’experience 

28. Rapport sur les risques 

11. Plan de gestion des changements 

11. Liste des jalons 

29. Donnees de I’echeancier 

12. Plan de gestion de la configuration 

12. Affectations des ressources materielles 

30. Previsions de I’echeancier 

13. Reference de base du perimetre 

13. Calendriers du projet 

31. Registre des parties prenantes 

14. Reference de base de I’echeancier 

14. Communications du projet 

32. Charte d’equipe 

15. Reference de base des couts 

15. Echeancier du projet 

33. Documents devaluation et de test 

16. Reference de base de la performance 

16. Diagramme de reseau du projet 

17. Description du cycle de vie du projet 

17. Enonce du perimetre du projet 

18. Approche de developpement 

18. Affectations des membres de I’equipe projet 


Les documents business sont des documents generalement crees en dehors du projet, et utilises en tant que donnees 
d’entree du projet. Parmi les documents business, on peut notamment citer le business case et le plan de gestion des 
benefices. L’utilisation de documents business dependra de la culture de I'organisation et des processus d’initialisation 
du projet. 

Les facteurs environnementaux de I'organisation qui ont une influence sur le projet et les actifs organisationnels 
disponibles dans le cadre du projet dependront de ce dernier et de son environnement; ils ne sont pas enumeres dans 
ce standard. 
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GROUPE DE PROCESSUS D’INITIALISATION 

Le groupe de processus d’initialisation inclut les processus qui permettent de definir un nouveau projet, ou une 
nouvelle phase d’un projet existant, avec I’obtention de I'autorisation de demarrer le projet ou la phase. Ce groupe de 
processus d’initialisation a pour objectif d’harmoniser les attentes des parties prenantes et I'objet du projet, de leur 
donner un apergu du perimetre et des objectifs, et de montrer comment leur participation au projet et aux phases qui lui 
sont associees peut assurer la satisfaction de leurs attentes. C’est dans les processus d’initialisation que le perimetre 
initial est defini et que les ressources financieres initiales sont engagees. Les parties prenantes qui vont interagir et 
influencer le resultat d'ensemble du projet sont identifies. Le chef de projet est alors selectionne, s’il n’est pas encore 
designe. Ces informations sont incluses dans la charte du projet et dans le registre des parties prenantes. Une fois la 
charte du projet approuvee, le projet est officiellement autorise et le chef de projet est habilite a affecter les ressources 
organisationnelles aux activites du projet. 

Ce groupe de processus a pour avantages principaux que seuls les projets conformes aux objectifs strategies de 
I’organisation sont autorises et que le business case, les benefices et les parties prenantes sont pris en consideration 
des le debut du projet. Dans certaines organisations, le chef de projet participe a I'elaboration du business case et 
determine les benefices. Dans ces organisations, le chef de projet aide generalement a rediger la charte du projet; dans 
d’autres organisations, le travail prealable au projet est effectue par le sponsor du projet, le bureau des projets (Project 
Management Office, PMO), le comite de pilotage du portefeuille ou d’autres groupes de parties prenantes. Le present 
standard suppose que le projet a ete approuve par le sponsor ou une autre instance de gouvernance et qu’ils ont passe 
en revue les documents business avant d'autoriser le projet. 

Les documents business sont des documents generalement crees en dehors du projet, mais ils sont utilises en tant 
que donnees d’entree du projet. Parmi les documents business, on peut notamment citer le business case et le plan 
de gestion des benefices. La figure 2-1 montre le lien entre le sponsor et les documents business, d’une part, et les 
processus d'initialisation, d’autre part. 
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Figure 2-1. Limites du projet 


Comme decrit a la section 1.5, les projets sont souvent divises en plusieurs phases. Ensuite, les informations 
emanant des processus dans le groupe de processus d’initialisation sont reexaminees afin de determiner si elles 
sont toujours valables. La revision des processus d’initialisation au debut de chaque phase permet de faire en sorte 
que le projet reste axe sur le besoin commercial auquel il doit repondre. La charte du projet, les documents business 
et les criteres de reussite sont verifies. L’influence, les motivations, les attentes et les objectifs des parties prenantes 
sont passes en revue. 

L'implication des sponsors, des clients et d’autres parties prenantes a la phase d’initialisation cree une comprehension 
partagee des criteres de reussite. Elle augmente egalement les chances que les livrables soientacceptes a I'achevement 
du projet, et que les parties prenantes soient satisfaites tout au long du projet. 

Le groupe de processus d’initialisation inclut les processus de management de projet recenses aux sections 2.1 a 2.2. 




Gestion de I’integration 
du projet 


Gestion des parties 
prenantes du projet 


V 


Elaborer 
la charte 
du projet 




Identifier 
les parties 
prenantes 



La fleche circulaire en pointilles indique que le processus fait 
partie du domaine de connaissance en gestion de I’integration 
du projet. Ce domaine de connaissance coordonne et unifie 
les processus a partir des autres domaines de connaissance. 


Figure 2-2. Groupe de processus d’initialisation 
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2.1 ELABORER LA CHARTE DU PROJET 


Elaborer la charte du projet est le processus consistant a developper un document qui autorise formellement 
I’existence d’un projet et donne autorite au chef de projet pour affecter des ressources de I’organisation aux activites 
de ce projet. L’interet principal de ce processus est qu’il offre un lien direct entre le projet et les objectifs strategies 
de I’organisation, cree une identification formelle du projet et montre I'engagement de I'organisation dans le cadre du 
projet. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. Les donnees d’entree et 
de sortie de ce processus sont representees sur la figure 2-3. 


Donnees d’entree 


.1 Documents business 
.2 Accords 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V___/ 


Donnees de sortie 


.1 Charte du projet 
.2 Journal des hypotheses 

V___/ 


Figure 2-3. Elaborer la charte du projet: donnees d’entree et donnees de sortie 


2.2 IDENTIFIER LES PARTIES PRENANTES 

Identifier les parties prenantes est le processus qui consiste a identifier regulierement les parties prenantes du projet 
mais aussi a analyser et a documenter des informations pertinentes concernant leurs interets, leur participation, leurs 
interdependances, leur influence et leur impact potentiel sur la reussite du projet. L’interet principal de ce processus 
est qu’il permet a I’equipe projet d’identifier I’orientation a suivre pour chaque partie prenante ou groupe de parties 
prenantes. Ce processus est execute periodiquement pendant toute la duree du projet. Les donnees d’entree et de sortie 
de ce processus sont representees sur la figure 2-4. 


Donnees d’entree 


.1 Charte du projet 
.2 Documents business 
.3 Plan de management du projet 
.4 Documents du projet 
.5 Accords 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 

V___> 


Donnees de sortie 


.1 Registre des parties prenantes 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

V___/ 


Figure 2-4. Identifier les parties prenantes: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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2.2.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

2.2.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ la documentation des exigences. 

2.2.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de 
ce processus, figurent entre autres : 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion de la communication ; 

♦ le plan de gestion des risques ; 

♦ le plan d’engagement des parties prenantes. 

2.2.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Les documents du projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus sont, notamment: 

♦ le journal des hypotheses ; 

♦ le journal des points a traiter; 

♦ le registre des risques. 
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GROUPE DE PROCESSUS DE PLANIFICATION 

Le groupe de processus de planification inclut les processus permettant d'etablir le perimetre total de I'effort, 
de definir et d’affiner les objectifs, et de developper la suite d’actions necessaires pour atteindre ces objectifs. 
Les processus du groupe de processus de planification developpent les composants du plan de management du 
projet et les documents de projet utilises pour executer le projet. La nature d’un projet peut exiger le recours a des 
boucles de retroaction repetees afin d’effectuer des analyses supplementaires. Une planification supplementaire 
sera vraisemblablement necessaire au fur et a mesure que de plus amples informations ou caracteristiques seront 
rassemblees et comprises. Les changements significatifs qui ont lieu tout au long du cycle de vie du projet peuvent 
necessiter de revoir un ou plusieurs processus de planification, voire I’un des processus d’initialisation ou les deux. 
Cette amelioration permanente du plan de management du projet est appelee elaboration progressive, pour indiquer 
le caractere iteratif et continu des activites de planification et de documentation. L’interet principal de ce groupe de 
processus est qu’il definit la marche a suivre pour mener a bien avec succes le projet ou la phase. 

L’equipe de management de projet cherche a obtenir des donnees d’entree, et encourage I'implication de toutes 
les parties prenantes concernees, lors de la planification du projet et de I'elaboration du plan de management et des 
documents du projet. Lorsque I'effort de planification initial est acheve, la version approuvee du plan de management 
du projet est consideree comme une reference de base. Tout au long du projet, les processus de maTtrise comparent la 
performance du projet aux references de base. 

Le groupe de processus de planification (figure 3-1) inclut les processus de management de projet recenses aux 
sections 3.1 a 3.24. 
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Gestion du perimetre 
du projet 


Gestion de lecheancier 
du projet 


Gestion des couts 
du projet 



La fleche circulaire en pointilles indique que le processus fait partie du domaine 
de connaissance en gestion de I’integration du projet. Ce domaine de connaissance 
coordonne et unifie les processus a partir des autres domaines de connaissance. 


Figure 3-1. Groupe de processus de planification 
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3.1 ELABORER LE PLAN DE MANAGEMENT DU PROJET 


L’elaboration du plan de management du projet est le processus consistant a definir, a preparer et a coordonner 
tous les composants du plan, et a les integrer dans un plan complet de management du projet. L’interet principal de ce 
processus est qu’il produit un document complet qui definit la base de tout le travail du projet et la fagon dont le travail 
sera accompli. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. Les donnees 
d’entree et de sortie de ce processus sont representees sur la figure 3-2. 



Donnees d’entree 


.1 Charte du projet 
.2 Donnees de sortie d'autres 
processus 

.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 


V_/ 

Figure 3-2. Elaborer le plan de management du projet: donnees d’entree et donnees de sortie 


Les besoins du projet determinent les composants du plan de management du projet et les documents necessaires. 


3.2 PLANIFIER LA GESTION DU PERIMETRE ET DU CONTENU 

Planifier la gestion du perimetre et du contenu est le processus qui consiste a creer un plan de gestion du perimetre 
qui documente la fagon dont le perimetre du projet sera defini, valide et maftrise. L’interet principal de ce processus est 
qu’il fournit les directives et les orientations de gestion du perimetre du projet tout au long du projet. Ce processus est 
execute une fois ou a des moments predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus 
sont representees sur la figure 3-3. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V___y 


Donnees de sortie 


.1 Plan de gestion du perimetre 
.2 Plan de gestion des exigences 

V_ 


Figure 3-3. Planifier la gestion du perimetre et du contenu : donnees d’entree et donnees de sortie 


Les besoins du projet determinent les composants necessaires au plan de management du projet. 
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3.2.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de la qualite; 

♦ la description du cycle de vie du projet; 

♦ I’approche de developpement. 


3.3 RECUEILLIR LES EXIGENCES 

Recueillir les exigences est le processus visant a determiner, a documenter et a gerer les besoins et les exigences 
des parties prenantes, dans le but d'atteindre les objectifs du projet. L’interet principal de ce processus est qu'il sert de 
base a la definition et a la gestion du contenu du produit et du perimetre du projet. Ce processus est execute une fois ou 
a des moments predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus sont representees 
sur la figure 3-4. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Documents business 
.5 Accords 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 

V___/ 


Donnees de sortie 


.1 Documentation des exigences 
.2 Matrice de tragabilite des 
exigences 

V___/ 


Figure 3-4. Recueillir les exigences: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.3.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ le plan de gestion des exigences ; 

♦ le plan d’engagement des parties prenantes. 
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3.3.2 EXEMPLES DE DOCUMENTS DE PROJET 


Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience; 

♦ le registre des parties prenantes. 


3.4 DEFINIR LE PERIMETRE 

Definir le perimetre est le processus qui consiste a elaborer une description detaillee du projet et du produit. L’interet 
principal de ce processus est qu’il decrit les limites du produit, du service ou du resultat et les criteres d’acceptation. 
Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. Les donnees d’entree et de 
sortie de ce processus sont representees sur la figure 3-5. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v_I_y 


Donnees de sortie 


.1 Enonce du perimetre du projet 
.2 Mises a jour des documents 
du projets 

v___y 


Figure 3-5. Definir le perimetre: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.4.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree de ce 
processus, figure notamment le plan de gestion du perimetre. 

3.4.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ la documentation des exigences ; 

♦ le registre des risques. 
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3.4.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des parties prenantes. 


3.5 CREER LE WBS 

Creer I'organigramme des travaux du projet (Work Breakdown Structure, WBS) est le processus qui consiste a 
subdiviser les livrables et le travail du projet en composants plus petits et plus faciles a gerer. L'interet principal de 
ce processus est qu’il fournit un cadre de ce qui doit etre livre. Ce processus est execute une fois ou a des moments 
predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-6. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V_I_/ 


.1 Reference de base 
du perimetre (voir note) 

.2 Mises a jour des documents 
du projet 

V___ 



Remarque: la reference de base du perimetre est la version approuvee 
de renonce du perimetre, du WBS et de son dictionnaire associe. 


Figure 3-6. Creer le WBS : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.5.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree de ce 
processus, figure notamment le plan de gestion du perimetre. 
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3.5.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ I’enonce du perimetre du projet; 

♦ la documentation des exigences. 

3.5.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent entre autres : 

♦ le journal des hypotheses ; 

♦ la documentation des exigences. 


3.6 PLANIFIER LA GESTION DE L’ECHEANCIER 

Planifier la gestion de I’echeancier est le processus qui consiste a etablir les politiques internes, les procedures 
et la documentation pour la planification, le developpement, la gestion, la realisation et la maTtrise de I'echeancier du 
projet. L’interet principal de ce processus est qu’il fournit les directives et les orientations de gestion de I'echeancier du 
projet tout au long du projet. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-7. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V_I_/ 


[ 


Donnees de sortie 


1 Plan de gestion de I'echeancier 


ierj 


Figure 3-7. Planifier la gestion de I’echeancier: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants necessaires au plan de management du projet. 
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3.6.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ I’approche de developpement. 


3.7 DEFINIR LES ACTIVITES 

Definir les activites est le processus qui consiste a identifier et a documenter les actions specifiques a effectuer 
pour produire les livrables du projet. L'interet principal de ce processus est qu’il decompose les lots de travaux en 
activites de I’echeancier qui servent de base a I'estimation, a la planification, a I'execution, a la maitrise du travail 
du projet. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont 
representees sur la figure 3-8. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Facteurs environnementaux 
de I’organisation 
.3 Actifs organisationnels 

v___y 


Donnees de sortie 


.1 Liste d'activites 
.2 Attributs des activites 
.3 Liste des jalons 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 

v_____y 


Figure 3-8. Definir les activites: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants necessaires au plan de management du projet. 


3.7.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base du perimetre. 

3.7.2 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d'etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 
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3.8 ORGANISER LES ACTIVITES EN SEQUENCE 

Organiser les activites en sequence est le processus qui consiste a identifier et a documenter les relations entre 
les activites du projet. L’interet principal de ce processus est qu’il definit la sequence logique de travail pour obtenir 
I’efficacite maximale compte tenu de toutes les contraintes du projet. Ce processus est execute tout au long du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-9. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V_I_ 


Donnees de sortie 


.1 Diagrammes de reseau 
du projet 

.2 Mises a jour des documents 
du projet 

V___/ 


Figure 3-9. Organiser les activites en sequence: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.8.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base du perimetre. 

3.8.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ les attributs des activites ; 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ la liste des jalons. 

3.8.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les attributs des activites ; 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ la liste des jalons. 
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3.9 ESTIMER LA DUREE DES ACTIVITIES 


Estimer la duree des activites est le processus qui consiste a estimer le nombre de periodes de travail requises 
pour accomplir chacune des activites avec leurs ressources estimees. L'interet principal de ce processus est qu’il 
chiffre le temps necessaire pour mener a bien chacune des activites. Ce processus est execute tout au long du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-10. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V_I_y 


.1 Estimations de durees 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

\___ J 


Figure 3-10. Estimer la duree des activites: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.9.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base du perimetre. 

3.9.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ les attributs des activites ; 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ les affectations des membres de I’equipe projet; 

♦ I’organigramme des ressources ; 

♦ les calendriers des ressources ; 

♦ les besoins en ressources; 

♦ le registre des risques. 
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3.9.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les attributs des activites ; 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience. 


3.10 ELABORER L’ECHEANCIER 

Elaborer I’echeancier est le processus qui consiste a analyser des sequences d’activites, des durees, des besoins 
en ressources et des contraintes de I’echeancier pour creer un modele d’echeancier a des fins d’execution et de 
maTtrise du projet. L’interet principal de ce processus est qu’il genere un modele d’echeancier fixant des dates pour 
I’achevement des activites du projet. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie 
de ce processus sont representees sur la figure 3-11. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Accords 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

V___y 


.1 Reference de base 
de I’echeancier 
.2 Echeancier du projet 
.3 Donnees de I'echeancier 
.4 Calendriers du projet 
.5 Demandes de changement 
.6 Mises a jour du plan 
de management du projet 
.7 Mises a jour des documents 
du projet 

--- 


Figure 3-11. Elaborer I’echeancier: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.10.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base du perimetre. 
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3.10.2 EXEMPLES DE DOCUMENTS DE PROJET 


Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ les attributs des activites ; 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ les estimations de durees ; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ le diagramme de reseau du projet; 

♦ les affectations des membres de I’equipe projet; 

♦ les calendriers des ressources ; 

♦ les besoins en ressources; 

♦ le registre des risques. 

3.10.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base des couts. 

3.10.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les attributs des activites ; 

♦ le journal des hypotheses ; 

♦ les estimations de durees ; 

♦ le registre des retours d’experience; 

♦ les besoins en ressources; 

♦ le registre des risques. 
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3.11 PLANIFIER LA GESTION DES COUTS 


Planifier la gestion des couts est le processus qui consiste a definir la maniere dont les couts du projet seront estimes, 
budgetes, geres et martrises. L’interet principal de ce processus est qu’il fournit les directives et les orientations sur la 
fagon de gerer les couts du projet tout au long du projet. Ce processus est execute une fois ou a des moments predefinis 
dans le cadre du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-12. 



Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 


V_/ 


Figure 3-12. Planifier la gestion des couts: donnees d’entree et donnees de sortie 


Les besoins du projet determinent les composants necessaires au plan de management du projet. 


3.11.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ le plan de gestion des risques. 


3.12 ESTIMER LES COOTS 

Estimer les couts est le processus qui consiste a evaluer les ressources monetaires necessaires a I’accomplissement 
du travail du projet. L’interet principal de ce processus est qu’il determine les ressources monetaires necessaires a 
I’accomplissement du projet. Ce processus est execute periodiquement pendant toute la duree du projet. Les donnees 
d’entree et de sortie de ce processus sont representees sur la figure 3-13. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V___y 


Donnees de sortie 


.1 Estimations de couts 
.2 Base des estimations 
.3 Mises a jour des documents 
du projet 

V___ J 


Figure 3-13. Estimer les couts: donnees d’entree et donnees de sortie 


Les besoins du projet determinent les composants du plan de management du projet et les documents necessaires. 


577 















3.12.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des couts ; 

♦ le plan de gestion de la qualite; 

♦ la reference de base du perimetre. 

3.12.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les besoins en ressources; 

♦ le registre des risques. 

3.12.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience; 

♦ le registre des risques. 

3.13 DETERMINER LE BUDGET 

Determiner le budget est le processus qui consiste a consolider les couts estimes, de chacune des activites ou 
de chacun des lots de travail, de fagon a etablir une reference de base des couts approuvee. L’interet principal de ce 
processus est qu’il determine la reference de base des couts qui peut etre utilisee comme element de comparaison pour 
maTtriser la performance du projet. Ce processus est execute une fois ou a des moments predefinis dans le cadre du 
projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-14. 
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Donnees d’entree 


Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Documents business 
.4 Accords 

.5 Facteurs environnementaux 


.1 Reference de base des couts 
.2 Besoin en financement 


du projet 

.3 Mises a jour des documents 


du projet 


de I'organisation 
.6 Actifs organisationnels 


Figure 3-14. Determiner le budget: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 

3.13.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des couts ; 

♦ le plan de gestion des ressources; 

♦ la reference de base du perimetre. 

3.13.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ la base des estimations ; 

♦ les estimations de couts ; 

♦ I’echeancier du projet; 

♦ le registre des risques. 

3.13.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les estimations de couts ; 

♦ I’echeancier du projet; 

♦ le registre des risques. 
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3.14 PLANIFIER LA GESTION DE LA QUALITE 

Planifier la gestion de la qualite est le processus qui consiste a identifier les exigences de qualite et/ou les standards 
a respecter pour le projet et ses livrables, et a documenter la fagon dont le projet demontrera sa conformite aux 
exigences et/ou aux standards de qualite appropries. L'interet principal de ce processus est qu’il fournit les directives 
et les orientations sur la fagon dont la qualite sera geree et verifiee tout au long du projet. Ce processus est execute 
une fois ou a des moments predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus sont 
representees sur la figure 3-15. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v_I_y 


Donnees de sortie 


.1 Plan de gestion de la qualite 
.2 Metriques qualite 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

v___y 


Figure 3-15. Planifier la gestion de la qualite : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.14.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion des risques ; 

♦ le plan d’engagement des parties prenantes ; 

♦ la reference de base du perimetre. 

3.14.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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3.14.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I’execution de 
ce processus, figurent entre autres : 

♦ le plan de gestion des risques ; 

♦ la reference de base du perimetre. 


3.14.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 


3.15 PLANIFIER LA GESTION DES RESSOURCES 

Planifier la gestion des ressources est le processus qui consiste a definir la methode d'estimation, d’obtention, de 
gestion et d’utilisation des ressources materielles et d’une equipe projet. L’interet principal de ce processus est qu’il 
etablit I’approche et le niveau d'effort necessaires a la gestion des ressources du projet en fonction du type et de la 
complexity de ce dernier. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-16. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I’organisation 
.5 Actifs organisationnels 
V___/ 


Donnees de sortie 


.1 Plan de gestion des ressources 
.2 Charte d'equipe 
.3 Mises a jour des documents 
du projet 

V___/ 


Figure 3-16. Planifier la gestion des ressources: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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3.15.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de la qualite; 

♦ la reference de base du perimetre. 

3.15.2 DOCUMENTS DU PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ I’echeancier du projet; 

♦ la documentation des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 

3.15.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le registre des risques. 


3.16 ESTIMER LES RESSOURCES NECESSAIRES AUX ACTIVITES 

Estimer les ressources necessaires aux activites est le processus qui consiste a evaluer les besoins en ressources 
d’une equipe mais aussi le type et les quantites de materiel, d’equipement et des fournitures necessaires a la realisation 
des travaux du projet. L’interet principal de ce processus est qu’il identifie le type, la quantite et les caracteristiques des 
ressources requises pour mener a bien le projet. Ce processus est execute periodiquement pendant toute la duree du 
projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-17. 
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Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V _I_/ 


Donnees de sortie 


.1 Besoins en ressources 
.2 Base des estimations 
.3 Organigramme des ressources 
.4 Mises a jour des documents 
du projet 

V___> 


Figure 3-17. Estimer les ressources necessaires aux activites : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.16.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ la reference de base du perimetre. 

3.16.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ les attributs des activites ; 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ les estimations de couts ; 

♦ les calendriers des ressources ; 

♦ le registre des risques. 

3.16.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les attributs des activites ; 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience. 
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3.17 PLANIFIER LA GESTION DES COMMUNICATIONS 


Planifier la gestion des communications est le processus qui consiste a elaborer une approche et un plan appropries 
pour les activites de communication du projet, conformement aux besoins en information de chaque partie prenante 
ou groupe, aux actifs organisationnels disponibles et aux besoins du projet. L’interet principal de ce processus reside 
dans une approche documentee qui permet d’engager les parties prenantes de maniere efficace et effective, en 
presentant des informations pertinentes en temps opportun. Ce processus est execute periodiquement pendant toute 
la duree du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-18. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 


Donnees de sortie 


.1 Plan de gestion de 
la communication 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 


Figure 3-18. Planifier la gestion des communications: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.17.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan d’engagement des parties prenantes. 

3.17.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ la documentation des exigences ; 

♦ le registre des parties prenantes. 

3.17.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Le plan d’engagement des parties prenantes est I’un des composants du plan de management du projet susceptibles 
d’etre mis a jour a la suite de I’execution de ce processus. 
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3.17.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ I’echeancier du projet; 

♦ le registre des parties prenantes. 


3.18 PLANIFIER LA GESTION DES RISQUES 

Planifier la gestion des risques est le processus qui consiste a definir comment conduire les activites de gestion 
des risques d’un projet. L’interet principal de ce processus est qu’il garantit que le niveau, le type et la visibilite de la 
gestion des risques sont correctement adaptes a la fois aux risques et a I'importance du projet pour ^organisation et les 
autres parties prenantes. Ce processus est execute une fois ou a des moments predefinis dans le cadre du projet. Les 
donnees d’entree et de sortie de ce processus sont representees sur la figure 3-19. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v___y 


[ 


Donnees de sortie 


1 Plan de gestion des risques 


3 


Figure 3-19. Planifier la gestion des risques: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.18.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Pour la planification de la gestion des risques du projet, tous les composants disponibles du plan de management 
du projet doivent etre pris en consideration afin de garantir que la gestion des risques est coherente avec les besoins 
du projet. 


3.18.2 EXEMPLES DE DOCUMENTS DE PROJET 

Le registre des parties prenantes est un exemple de document de projet pouvant constituer des donnees d’entree 
pour ce processus. 
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3.19 IDENTIFIER LES RISQUES 


Identifier les risques est le processus qui inclut I’identification des risques individuels et des sources du risque global 
du projet ainsi qu’a en documenter les caracteristiques. L’interet principal de ce processus reside dans la documentation 
des risques individuels existants dans le cadre du projet et des sources du risque global du projet. II permet egalement 
de reunir des informations qui permettent a I'equipe projet de repondre de maniere appropriee aux risques identifies. 
Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont representees 


sur la figure 3-20. 



.1 Plan de management du projet 


.1 Registre des risques 


.2 Documents du projet 


.2 Rapport sur les risques 


.3 Accords 


.3 Mises a jour des documents 


.4 Documents d'approvisionnements 


du projet 


.5 Facteurs environnementaux 


^ J 


de I’organisation 



.6 Actifs organisationnels 



v___/ 


Donnees de sortie 


Donnees d’entree 


Figure 3-20. Identifier les risques: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.19.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion de I’echeancier; 

♦ le plan de gestion des couts ; 

♦ le plan de gestion de la qualite; 

♦ le plan de gestion des ressources; 

♦ le plan de gestion des risques ; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 
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3.19.2 EXEMPLES DE DOCUMENTS DE PROJET 


Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ les estimations de couts ; 

♦ les estimations de durees ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ les besoins en ressources; 

♦ le registre des parties prenantes. 

3.19.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience. 
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3.20 EFFECTUER L’ANALYSE QUALITATIVE DES RISQUES 


Effectuer I’analyse qualitative des risques est le processus qui consiste a hierarchiser les risques individuels du 
projet afin de les analyser ou de les exploiter ulterieurement en evaluant leur probability d’occurrence ou leur impact 
parmi d’autres caracteristiques. L’interet principal de ce processus est qu’il concentre les efforts sur les risques a 
priority elevee. Ce processus est execute tout au long du projet, Les donnees d’entree et de sortie de ce processus sont 
representees sur la figure 3-21. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
V_I_/ 


Donnees de sortie 


.1 Mises a jour des documents 
du projet 

V___y 


Figure 3-21. Effectuer I’analyse qualitative des risques : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.20.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion des risques est I’un des composants du plan de management du projet susceptibles de 
constituer des donnees d’entree de ce processus. 


3.20.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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3.20.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le journal des points a traiter; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 


3.21 EFFECTUER L’ANALYSE QUANTITATIVE DES RISQUES 

Effectuer I'analyse quantitative des risques est le processus qui consiste a analyser de fagon mesurable I’effet 
combine des risques individuels du projet identifies et des autres sources d’incertitudes sur I'ensemble des objectifs 
du projet. L'interet principal de ce processus est qu’il quantifie I'exposition au risque global du projet et qu’il peut aussi 
fournir des informations quantitatives sur les risques supplementaires afin de contribuer a la planification de la reponse 
aux risques. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont 
representees sur la figure 3-22. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V _I_/ 


Donnees de sortie 


.1 Mises a jour des documents 
du projet 

V _/ 


Figure 3-22. Effectuer I’analyse quantitative des risques: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.21.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des risques ; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 
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3.21.2 EXEMPLES DE DOCUMENTS DE PROJET 


Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ les estimations de couts ; 

♦ les previsions de couts ; 

♦ les estimations de durees ; 

♦ la liste des jalons ; 

♦ les besoins en ressources; 

♦ le registre des risques ; 

♦ le rapport sur les risques ; 

♦ les previsions de I’echeancier. 

3.21.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figure le rapport sur les risques. 


3.22 PLANIFIER LES REPONSES AUX RISQUES 

Planifier les reponses aux risques est le processus qui consiste a developper des options, selectionner des strategies 
et convenir d'actions visant a gerer I'exposition au risque global du projet mais aussi a traiter chaque risque individuel 
du projet. L'interet principal de ce processus est qu’il identifie les moyens adequats de gerer le risque global du projet 
et les risques individuels du projet. En outre, ce processus affecte les ressources et integre les activites dans les 
documents du projet et le plan de management du projet. Ce processus est execute tout au long du projet. Les donnees 
d’entree et de sortie de ce processus sont representees sur la figure 3-23. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V. _I_/ 


Donnees de sortie 


.1 Demandes de changement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

v___y 


Figure 3-23. Planifier les reponses aux risques : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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3.22.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion des risques ; 

♦ la reference de base des couts. 

3.22.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les affectations des membres de I’equipe projet; 

♦ les calendriers des ressources ; 

♦ le registre des risques ; 

♦ le rapport sur les risques ; 

♦ le registre des parties prenantes 

3.22.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de I’echeancier; 

♦ le plan de gestion des couts ; 

♦ le plan de gestion de la qualite; 

♦ le plan de gestion des ressources; 

♦ le plan de gestion des approvisionnements ; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 
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3.22.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ les previsions de couts ; 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les affectations des membres de I’equipe projet; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 


3.23 PLANIFIER LA GESTION DES APPROVISIONNEMENTS 

Planifier la gestion des approvisionnements est le processus qui consiste a documenter les decisions 
d’approvisionnement du projet, a specifier les approches, et a identifier les fournisseurs potentiels. L’interet principal 
de ce processus est qu’il permet de decider d’acquerir ou non des biens et des services a I’exterieur du projet et, le 
cas echeant, ce qu’il faut acquerir, comment et quand. L’approvisionnement en biens et services peut se faire aupres 
d’autres parties de I'organisation realisatrice ou aupres de sources externes. Ce processus est execute une fois ou a 
des moments predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus sont representees 
sur la figure 3-24. 


Donnees d’entree V Donnees de sortie 


.1 Charte du projet 
.2 Documents business 
.3 Plan de management du projet 
.4 Documents du projet 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
V___/ 


.1 Plan de gestion 

des approvisionnements 
.2 Strategie d'approvisionnement 
.3 Documents d'appel d'offres 
.4 Enonce des travaux 
d'approvisionnement 
.5 Criteres de selection 
des sources 

.6 Decisions « make-or-buy » 

.7 Estimations independantes 
des couts 

.8 Demandes de changement 
.9 Mises a jour des documents 
du projet 

.10 Mises a jour des actifs 
organisationnels 

V_/ 


Figure 3-24. Planifier la gestion des approvisionnements: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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3.23.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ le plan de gestion de la qualite; 

♦ le plan de gestion des ressources; 

♦ la reference de base du perimetre. 

3.23.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ la liste des jalons ; 

♦ les affectations des membres de I’equipe projet; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ les besoins en ressources; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 

3.23.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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3.24 PLANIFIER L’ENGAGEMENT DES PARTIES PRENANTES 


Planifier I’engagement des parties prenantes est le processus qui consiste a developper des approches pour 
impliquer les parties prenantes du projet, en fonction de leurs besoins, de leurs attentes, de leurs interets et de leur 
impact potentiel sur le projet. L’interet principal de ce processus est qu’il fournit un plan fondamental pour interagir 
efficacement avec les parties prenantes. Ce processus est execute periodiquement pendant toute la duree du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 3-25. 


Donnees d’entree 


.1 Charte du projet 
.2 Plan de management du projet 
.3 Documents du projet 
.4 Accords 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 

v___/ 


Donnees de sortie 


.1 Plan d'engagement des 
parties prenantes 

V_„_/ 


Figure 3-25. Planifier (’engagement des parties prenantes : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


3.24.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion de la communication ; 

♦ le plan de gestion des risques. 

3.24.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ I’echeancier du projet; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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GROUPE DE PROCESSUS D’EXECUTION 

Le groupe de processus d'execution inclut les processus permettant de realiser le travail defini dans le plan de 
management du projet pour satisfaire aux exigences du projet. Ce groupe de processus implique la coordination des 
ressources, la gestion de I'engagement des parties prenantes, ainsi que I’integration et la conduite des activites du 
projet conformement au plan de management du projet. L’interet principal de ce groupe de processus est que le travail 
requis pour satisfaire aux exigences et aux objectifs du projet est realise conformement au plan. Une part importante 
du budget, des ressources et du temps du projet est consacree a la realisation des processus du groupe de processus 
d’execution. Les processus du groupe de processus d’execution peuvent generer des demandes de changement. 
Si elles sont approuvees, les demandes de changement peuvent declencher un ou plusieurs processus de planification 
qui creent un plan de gestion, des documents de projet, voire de nouvelles references de base changees. Le groupe 
de processus d’execution (figure 4-1) inclut les processus de management de projet recenses aux sections 4.1 a 4.10. 
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Gestion de la qualite 
du projet 


Gestion des parties 
prenantes du projet 


Gerer 

I’engagement 
des parties 
prenantes 




Gestion de I'integration 
du projet 


Gestion 
des approvisionnements 
du projet 


Proceder aux 
approvisionnements 


A 



Gerer I I 

les connaissances 
du projet 


Gestion des ressources 
du projet 




Gestion 

des communications 
du projet 


Gestion des risques 
du projet 

Executer 
les reponses 
aux risques 


Gerer les 
communications 


La fleche circulaire en pointilles indique que le processus fait partie du domaine de connaissance en gestion de I’integration 
du projet. Ce domaine de connaissance coordonne et unifie les processus a partir des autres domaines de connaissance. 


Figure 4-1. Groupe de processus d’execution 
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4.1 DIRIGER ET GERER LE TRAVAIL DU PROJET 


Diriger et gerer le travail du projet est le processus qui consiste a diriger et a realiser le travail defini dans le plan 
de management du projet et a appliquer les changements approuves pour atteindre les objectifs du projet. L’interet 
principal de ce processus est qu’il garantit une gestion globale du travail et des livrables du projet, ameliorant ainsi ses 
chances de reussite. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus 
sont representees sur la figure 4-2. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Demandes de changement 
approuvees 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

V___/ 


.1 Livrables 

.2 Donnees de performance 
d'execution 

.3 Journal des points a traiter 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour des documents 
du projet 

.7 Mises a jour des actifs 
organisationnels 

v _y 


Figure 4-2. Diriger et gerer le travail du projet: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 

4.1.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent constituer des donnees d’entree pour ce processus. 

4.1.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des changements; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ les communications du projet; 

♦ I’echeancier du projet; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 
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4.1.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent etre mis a jour a la suite de ce processus. 

4.1.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ la liste d’activites; 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 


4.2 GERER LES CONNAISSANCES DU PROJET 

Gerer les connaissances du projet est le processus qui consiste a utiliser les connaissances existantes et a acquerir 
de nouvelles connaissances pour atteindre les objectifs du projet et contribuer a I'apprentissage organisationnel. 
L’interet principal de ce processus est que les connaissances organisationnelles preambles sont exploitees pour 
produire ou ameliorer les resultats du projet et que les retours d’experience tires du projet sont disponibles pour 
soutenir les operations organisationnelles et les futurs projets ou phases. Ce processus est execute tout au long du 
projet. Les donnees d’entree et de sortie de ce processus sont presentees a la figure 4-3. 



r ; ; i 

Donnees d’entree 


r Donnees de sortie 


.1 Plan de management du projet 


.1 Registre des retours 


.2 Documents du projet 


d’experience 


.3 Livrables 


.2 Mises a jour du plan 


.4 Facteurs environnementaux 


de management du projet 


de I'organisation 


.3 Mises a jour des actifs 


.5 Actifs organisationnels 


organisationnels 


Figure 4-3. Gerer les connaissances du projet: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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4.2.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent constituer des donnees d’entree pour ce processus. 

4.2.2 DOCUMENTS DU PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ les affectations des membres de I’equipe projet; 

♦ I’organigramme des ressources ; 

♦ les criteres de selection des sources ; 

♦ le registre des parties prenantes. 

4.2.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent etre mis a jour a la suite de ce processus. 


4.3 GERER LA QUALITE 

Gerer la qualite est le processus qui consiste a transformer le plan de gestion de la qualite en activites realisables 
dans ce domaine tout en integrant au projet les politiques qualite de I'organisation. L'interet principal de ce processus 
est qu’il augmente les chances d'atteindre les objectifs en termes de qualite et d'identifier les processus inefficaces 
et les causes de mauvaise qualite. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie 
de ce processus sont representees sur la figure 4-4. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Actifs organisationnels 

v___y 


Donnees de sortie 


.1 Rapport de qualite 
.2 Documents devaluation 
et de test 

.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du pro jet 

V___/ 


Figure 4-4. Gerer la qualite: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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4.3.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion de la qualite est I'un des composants du plan de management du projet susceptibles de constituer 
des donnees d’entree de ce processus. 

4.3.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ les mesures de controle de la qualite; 

♦ les metriques qualite ; 

♦ le rapport sur les risques. 

4.3.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d'etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de la qualite; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 

4.3.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques. 
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4.4 OBTENIR LES RESSOURCES 


Obtenir les ressources est le processus qui consiste a recruter les membres d’une equipe ainsi qu’a obtenir les 
infrastructures, les equipements, le materiel, les fournitures ettoutes les autres ressources necessaires a la realisation 
des travaux du projet. L’interet principal de ce processus est qu’il presente et oriente la selection des ressources 
et les affecte aux differentes activites. Ce processus est execute periodiquement pendant toute la duree du projet. Les 
donnees d’entree et de sortie de ce processus sont representees sur la figure 4-5. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 

V _ZZ_/ 


.1 Affectations des ressources 
materielles 

.2 Affectations des membres 
de I’equipe projet 
.3 Caiendriers des ressources 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour des documents 
du pro jet 

.7 Mises a jour des facteurs 
environnementaux 
de I'organisation 
.8 Mises a jour des actifs 
organisationnels 

V_ 


Figure 4-5. Obtenir les ressources : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


4.4.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion des approvisionnements ; 

♦ la reference de base des couts. 

4.4.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ I’echeancier du projet; 

♦ les caiendriers des ressources ; 

♦ les besoins en ressources; 

♦ le registre des parties prenantes. 
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4.4.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des ressources; 

♦ la reference de base des couts. 

4.4.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ I’organigramme des ressources ; 

♦ calendriers des ressources; 

♦ les besoins en ressources; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 


4.5 DEVELOPPER L’EQUIPE 

Developper I'equipe est le processus qui consiste a ameliorer les competences des membres de I'equipe, leurs 
interactions et I’environnement global de I’equipe, afin d’ameliorer la performance du projet. L’interet principal de ce 
processus est qu’il se traduit par un meilleur travail d’equipe, une mise en valeur des competences interpersonnelles 
et des membres de I’equipe, des employes motives, une reduction du taux de rotation du personnel et une amelioration 
globale des performances du projet. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie 


Inputs V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I'organisation 
.4 Actifs organisationnels 
---y 


.1 Evaluations des performances 
de I'equipe 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

.5 Mises a jour des facteurs 
environnementaux 
de I'organisation 
.6 Mises a jour des actifs 
organisationnels 

v_y 


de ce processus sont representees sur la figure 4-6. 


Figure 4-6. Developper I’equipe : donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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4.5.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Le plan de gestion des ressources est I'un des composants du plan de management du projet susceptible de 
constituer des donnees d’entree de ce processus. 

4.5.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les affectations des membres de I’equipe projet; 

♦ les calendriers des ressources ; 

♦ la charte d’equipe. 

4.5.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion des ressources est I’un des composants du plan de management du projet susceptibles d'etre mis 
a jour suite a I'execution de ce processus. 

4.5.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents de projet susceptibles d’etre mis a jour a la suite de I’execution de ce processus figurent, notamment: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les affectations des membres de I’equipe projet; 

♦ les calendriers des ressources ; 

♦ la charte d’equipe. 
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4.6 GERER L’EQUIPE 

Gerer I’equipe est le processus qui consiste a suivre la performance des membres de I’equipe, a fournir des retours 
d’information, a resoudre des points a traiter et a gerer des changements dans I’equipe pour optimiser la performance 
du projet. L’interet principal de ce processus est qu’il permet d’influencer le comportement de i’equipe, de gerer les 
conflits et de resoudre les points a traiter. Ce processus est execute tout au long du projet. Les donnees d’entree et de 
sortie de ce processus sont representees sur la figure 4-7. 


Donnees d’entree W Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Rapports sur la performance 
d'execution 

.4 Evaluations des performances 
de 1'equipe 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
V___/ 


.1 Demandes de changement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

.4 Mises a jour des facteurs 
environnementaux 
de I'organisation 

---y 


Figure 4-7. Gerer I’equipe: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


4.6.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion des ressources est I’un des composants du plan de management du projet susceptible de 
constituer des donnees d’entree de ce processus. 


4.6.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les affectations des membres de I’equipe projet; 

♦ la charte d’equipe. 
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4.6.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des ressources; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 

4.6.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les affectations des membres de I'equipe projet. 


4.7 GERER LES COMMUNICATIONS 

Gerer les communications est le processus qui consiste a assurer, de maniere appropriee et en temps utile, la 
collecte, la creation, la distribution, le stockage, la recherche, la gestion, la maTtrise et la mise a disposition finale des 
informations du projet. L’interet principal de ce processus est qu’il offre un flux d’information efficace entre I’equipe 
projet et les parties prenantes. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce 
processus sont representees sur la figure 4-8. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Rapports sur la performance 
d’execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v___y 


Donnees de sortie 


.1 Communications du projet 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

.4 Mises a jour des actifs 
organisationnels 

v_y 


Figure 4-8 Gerer les communications: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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4.7.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

4.7.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le rapport de qualite; 

♦ le rapport sur les risques ; 

♦ le registre des parties prenantes. 

4.7.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de 
ce processus figurent, entre autres : 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

4.7.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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4.8 EXECUTER LES REPONSES AUX RISQUES 

Executer les reponses aux risques est le processus qui consiste a appliquer les plans de reponse aux risques 
convenus. L’interet principal de ce processus est qu’il garantit que les plans de reponse aux risques convenus sont 
executes comme prevu afin de gerer I'exposition au risque global du projet mais aussi de minimiser les menaces 
individuelles du projet et de maximiser les opportunity individuelles du projet. Ce processus est execute tout au long du 
projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 4-9. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Actifs organisationnels 


Donnees de sortie 


.1 Demandes de changement 
.2 Mises a jour des documents 
du projet 


Figure 4-9. Executer les reponses aux risques: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


4.8.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion des risques est I’un des composants du plan de management du projet susceptibles de constituer 
des donnees d’entree de ce processus. 


4.8.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 

4.8.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les affectations des membres de I’equipe projet; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 
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4.9 PROCEDER AUX APPROVISIONNEMENTS 


Proceder aux approvisionnements est le processus qui consiste a obtenir les reponses des vendeurs, a en selectionner 
un et a attribuer un contrat. L’interet principal de ce processus est qu’il permet de selectionner un fournisseur qualifie et 
d’appliquer I’accord juridique necessaire a la livraison. Ce processus est execute periodiquement pendant toute la duree 
du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 4-10. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Documents d'approvisionnements 
.4 Propositions des vendeurs 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 


.1 Vendeurs selectionnes 
.2 Accords 

.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du projet 

.6 Mises a jour des actifs 
organisationnels 

v_y 


Figure 4-10. Proceder aux approvisionnements: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 

4.9.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion de la communication ; 

♦ le plan de gestion des risques ; 

♦ le plan de gestion des approvisionnements ; 

♦ le plan de gestion de la configuration ; 

♦ la reference de base des couts. 
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4.9.2 EXEMPLES DE DOCUMENTS DE PROJET 


Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ la documentation des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 

4.9.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion de la qualite; 

♦ le plan de gestion de la communication ; 

♦ le plan de gestion des risques ; 

♦ le plan de gestion des approvisionnements ; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 

4.9.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ les calendriers des ressources ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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4.10 GERER L’ENGAGEMENT DES PARTIES PRENANTES 


Gerer I'engagement des parties prenantes est le processus qui consiste a communiquer et a travailler avec les parties 
prenantes afin de satisfaire leurs besoins et leurs attentes, de gerer les points a traiter et de les encourager a participer 
de maniere adequate. L’interet principal de ce processus est qu’il permet au chef de projet d'accroTtre le soutien des 
parties prenantes et de minimiser leur resistance. Ce processus est execute tout au long du projet. Les donnees d’entree 
et de sortie de ce processus sont representees sur la figure 4-11. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Facteurs environnementaux 
de I’organisation 
.4 Actifs organisationnels 
V___/ 


Donnees de sortie 


.1 Demandes de changement 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

v___/ 


Figure 4-11. Gerer I’engagement des parties prenantes: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


4.10.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de la communication ; 

♦ le plan de gestion des risques ; 

♦ le plan d’engagement des parties prenantes ; 

♦ le plan de gestion des changements. 

4.10.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des parties prenantes. 
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4.10.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

4.10.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des parties prenantes. 
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GROUPE DE PROCESSUS DE MAITRISE 

Le groupe de processus de maitrise inclut les processus permettant de suivre, de passer en revue et de reguler 
I'avancement et la performance du projet, d'identifier les endroits ou des changements du plan s’averent necessaires, 
et d’apporter les changements correspondants. La martrise consiste a collecter les donnees de performance du projet, 
definir des mesures de performance, generer des rapports et diffuser les informations correspondantes. La maitrise 
consiste a comparer les performances reelles aux performances prevues, analyser les ecarts, evaluer les tendances 
dans le but d’ameliorer les processus, evaluer les alternatives possibles et recommander les actions correctives 
appropriees. L'interet principal de ce groupe de processus est que la performance du projet est mesuree et analysee a 
intervals reguliers, a I’occasion d’evenements appropries ou lors de I’occurrence d'elements exceptionnels, de fagon 
a identifier et a eliminer les ecarts par rapport au plan de management du projet. Le groupe de processus de maitrise 
implique egalement: 

♦ revaluation des demandes de changement et la determination de la reponse appropriee ; 

♦ la recommandation d’actions preventives ou correctives en anticipation de problemes eventuels ; 

♦ la maitrise des activites en cours du projet par rapport au plan de management du projet et aux references de 
base du projet; 

♦ des actions pour influencer les facteurs qui permettraient de contourner le processus de maitrise des 
changements, afin que seuls les changements approuves soient appliques. 

Cette martrise continue apporte a I'equipe projet et aux autres parties prenantes un apergu sur I’etat du projet et 
identifie les domaines requerant une attention supplemental. Le groupe de processus de maitrise evalue le travail 
effectue au sein de chaque domaine de connaissance, de chaque groupe de processus, de chaque phase du cycle de vie 
et du projet dans son ensemble. Le groupe de processus de maitrise (figure 5-1) inclut les processus de management 
de projet recenses aux sections 5.1 a 5.12. 
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Gestion du perimetre 
du projet 



Gestion de I'echeancier 
du projet 


Mattriser 

I’echeancier 


Gestion des parties 
prenantes du projet 


Mattriser 
I’engagement 
des parties 
prenantes 


Gestion 
des approvisionnements 
du projet 


Mattriser les 
approvisionnements 




Gestion de I'integration 
du projet 





Gestion des risques 
du projet 


Mattriser 
les risques 


Gestion des couts 
du projet 


Mattriser 
les couts 


Gestion de ia qualite 
du projet 


Mattriser 
la qualite 


Gestion des ressources 
du projet 


Mattriser 
les ressources 


Gestion 
des communications 
du projet 


Mattriser les 
communications 


La fleche circulaire en pointilles indique que le processus fait partie du domaine de connaissance en gestion de I’integration 
du projet. Ce domaine de connaissance coordonne et unifie les processus a partir des autres domaines de connaissance. 


Figure 5-1. Groupe de processus de maitrise 
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5.1 MAITRISER LE PROJET 


MaTtriser le projet est le processus qui consiste a suivre, passer en revue et communiquer I’avancement global par 
rapport aux objectifs de performance definis dans le plan de management du projet. L’interet principal de ce processus 
est qu’il permet aux parties prenantes de comprendre I'etat actuel du projet, de reconnaTtre les mesures prises pour 
traiter les problemes de performance et d’avoir une visibility sur I'etat futur du projet avec des previsions de I'echeancier 
et des couts. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont 
representees sur la figure 5-2. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Informations sur 

la performance d'execution 
.4 Accords 

.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 

v_I_y 


Donnees de sortie 


.1 Rapports sur la performance 
d'execution 

.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

v___y 


Figure 5-2. Maitriser le projet: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


5.1.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent constituer des donnees d’entree pour ce processus. 

5.1.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ les previsions de couts ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ les rapports qualite; 

♦ le registre des risques ; 

♦ le rapport sur les risques ; 

♦ les previsions de I’echeancier. 
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5.1.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent etre mis a jour a la suite de ce processus. 

5.1.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ les previsions de couts ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ les previsions de I'echeancier. 


5.2 MAITRISER LES CHANGEMENTS 

MaTtriser les changements est le processus qui consiste a passer en revue toutes les demandes de changement, 
puis approuver et gerer les changements apportes aux livrables, aux actifs organisationnels, aux documents et au 
plan de management du projet, puis communiquer les decisions. Ce processus passe en revue toutes les demandes 
de changement concernant les documents du projet, les livrables ou le plan de management du projet, et determine 
la reponse a donner a ces demandes. L’interet principal de ce processus est qu’il permet de considerer les changements 
documents au sein du projet de maniere integree, tout en gerant le risque global du projet, qui survient souvent 
en consequence de changements effectues sans tenir compte des plans ou des objectifs globaux du projet. 
Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont representees 
sur la figure 5-3. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Rapports sur la performance 
d’execution 

.4 Demandes de changement 
.5 Facteurs environnementaux 
de I'organisation 
.6 Actifs organisationnels 
V___/ 


Donnees de sortie 


.1 Demandes de changement 
approuvees 
.2 Mises a jour du plan 
de management du projet 
.3 Mises a jour des documents 
du projet 

V___/ 


Figure 5-3. Maitriser les changements: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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5.2.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des changements ; 

♦ le plan de gestion de la configuration ; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 

5.2.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ la base des estimations ; 

♦ la matrice de tragabilite des exigences ; 

♦ le rapport sur les risques. 

5.2.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent etre mis a jour a la suite de ce processus. 


5.2.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Tout document du projet officiellement maTtrise peut etre modifie a la suite de ce processus. Un document de projet 
generalement mis a jour a la suite de ce processus est le journal des changements. Ce dernier sert a documenter les 
changements qui ont lieu au cours du projet. 


617 



5.3 VALIDER LE PERIMETRE 


Valider le perimetre est le processus qui consiste a formaliser I’acceptation des livrables du projet termines. L’interet 
principal de ce processus est qu’il confere un caractere objectif au processus d'acceptation et accroTt les chances 
d’acceptation du produit, du service ou du resultat final en validant chacun des livrables. Ce processus est execute 
periodiquement pendant toute la duree du projet. Les donnees d’entree et de sortie de ce processus sont representees 
sur la figure 5-4. 


r ^ 

Donnees d’entree 


r ; ; ^ 

Donnees de sortie 

.1 Plan de management du projet 
.2 Documents du projet 
.3 Livrables verifies 
.4 Donnees de performance 
d'execution 

V_I_ ) 


.1 Livrables acceptes 
.2 Informations sur 

la performance d'execution 
.3 Demandes de changement 
.4 Mises a jour des documents 
du projet 

v y 

1 


Figure 5-4. Valider le perimetre: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


5.3.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ le plan de gestion des exigences ; 

♦ la reference de base du perimetre. 

5.3.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ les rapports qualite; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences. 
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5.3.3 MISES A JOUR DES DOCUMENTS DU PROJET 


Les documents du projet susceptibles d'etre mis a jour a la suite de I’execution de ce processus sont, notamment: 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences. 


5.4 MAITRISER LE PERIMETRE 

MaTtriser le perimetre est le processus qui consiste a suivre I’etat du perimetre du projet et du contenu du 
produit et a gerer les changements affectant la reference de base du perimetre. L’interet principal de ce processus 
est qu’il permet de conserver la reference de base du perimetre tout au long du projet. Ce processus est execute 
tout au long du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-5. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 

.4 Actifs organisationnels 
V___/ 


Donnees de sortie 


.1 Informations sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

V___/ 


Figure 5-5. Maitriser le perimetre: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


5.4.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion du perimetre; 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion des changements ; 

♦ le plan de gestion de la configuration ; 

♦ la reference de base du perimetre; 

♦ la reference de base de la performance. 
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5.4.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences. 

5.4.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ le plan de gestion du perimetre; 

♦ la reference de base du perimetre; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts ; 

♦ la reference de base de la performance. 

5.4.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences. 
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5.5 MAITRISER L’ECHEANCIER 


MaTtriser I’echeancier est le processus qui consiste a suivre I’etat du projet, dans le but de reviser I’echeancier du 
projet et de gerer les changements affectant la reference de base de I’echeancier. L’interet principal de ce processus 
est qu’il permet de conserver la reference de base de I'echeancier tout au long du projet. Ce processus est execute tout 
au long du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-6. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 

.4 Actifs organisationnels 

V___ 


.1 Informations sur 

la performance d'execution 
.2 Previsions de I'echeancier 
.3 Demandes de changement 
.4 Mises a jour du plan 
de management du projet 
.5 Mises a jour des documents 
du projet 

V___y 


Figure 5-6. Maitriser I’echeancier: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


5.5.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base de I’echeancier; 

♦ la reference de base du perimetre; 

♦ la reference de base de la performance. 

5.5.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ les calendriers du projet; 

♦ I’echeancier du projet; 

♦ les calendriers des ressources ; 

♦ les donnees de I’echeancier. 
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5.5.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 


Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de I’echeancier; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts ; 

♦ la reference de base de la performance. 

5.5.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ le registre des retours d’experience; 

♦ I’echeancier du projet; 

♦ les calendriers des ressources ; 

♦ le registre des risques ; 

♦ les donnees de I'echeancier. 


5.6 MAITRISER LES COUTS 


MaTtriser les couts est le processus qui consiste a suivre I’etat du projet, dans le but de reviser les couts du projet et 
de gerer les changements affectant la reference de base des couts. L’interet principal de ce processus est qu’il permet 
de conserver la reference de base des couts tout au long du projet. Ce processus est execute tout au long du projet. 
Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-7. 



.1 Plan de management du projet 
.2 Documents du projet 
.3 Besoin en financement 


.1 Informations sur 


la performance d'execution 
.2 Previsions de couts 
.3 Demandes de changement 
.4 Mises a jour du plan 


du projet 

.4 Donnees de performance 


d'execution 

.5 Actifs organisationnels 


de management du projet 
.5 Mises a jour des documents 


V 


J du projet 


V 


Figure 5-7. Maitriser les couts: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants necessaires au plan de management du projet. 
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5.6.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des couts ; 

♦ la reference de base des couts ; 

♦ la reference de base de la performance. 

5.6.2 EXEMPLES DE DOCUMENTS DE PROJET 

Le registre des retours d’experience est un exemple de document de projet susceptible de constituer des donnees 
d’entree pour ce processus. 

5.6.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I’execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des couts ; 

♦ la reference de base des couts ; 

♦ la reference de base de la performance. 

5.6.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ les estimations de couts ; 

♦ le registre des retours d’experience; 

♦ le registre des risques. 
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5.7 MAITRISER LA QUALITE 

MaTtriser la qualite est le processus qui consiste a maitriser et enregistrer les resultats des activites de gestion de la 
qualite pour evaluer la performance et s’assurer que les produits du projet sont exhaustifs, conformes et satisfont aux 
attentes du client. L’interet principal de ce processus est qu’il permet de verifier que les travaux et les livrables du projet 
repondent aux exigences specifies par les principales parties prenantes pour I’acceptation finale. Ce processus est 
execute tout au long du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-8. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Demandes de changement 
approuvees 
.4 Livrables 

.5 Donnees de performance 
d'execution 

.6 Facteurs environnementaux 
de I'organisation 
.7 Actifs organisationnels 

v___y 

Figure 5-8. Maitriser la qualite : 


Donnees de sortie 


.1 Mesures de controle 
de la qualite 
.2 Livrables verifies 
.3 Informations sur 

la performance d'execution 
.4 Demandes de changement 
.5 Mises a jour du plan 
de management du projet 
.6 Mises a jour des documents 
du projet 

v___y 

ees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


5.7.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion de la qualite est I’un des composants du plan de management du projet susceptibles de 
constituer des donnees d’entree de ce processus. 


5.7.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le registre des retours d’experience; 

♦ les metriques qualite ; 

♦ les documents devaluation et de test. 


624 


Deuxieme partie - Le Standard 









5.7.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Le plan de gestion de la qualite est I’un des composants du plan de management du projet susceptibles d’etre mis a jour 
a la suite de I’execution de ce processus. 


5.7.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ les documents devaluation et de test. 


5.8 MAITRISER LES RESSOURCES 

MaTtriser les ressources est le processus qui consiste a s’assurer de la disponibilite des ressources affectees au 
projet, conformement aux previsions, a en suivre I’utilisation reelle par rapport aux planifications et a mettre en place 
des actions correctives, le cas echeant. L’interet principal de ce processus est qu’il veille a ce que les ressources 
affectees soient mises a la disposition du projet au bon moment et au bon endroit, et qu’elles soient liberties des qu’elles 
ne sont plus necessaires. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce 
processus sont representees sur la figure 5-9. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 
.4 Accords 

.5 Actifs organisationnels 

V___ J 


Donnees de sortie 


.1 Informations sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

v___y 


Figure 5-9. Maitriser les ressources: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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5.8.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Le plan de gestion des ressources est I’un des composants du plan de management du projet susceptible de constituer 
des donnees d’entree de ce processus. 

5.8.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les affectations des ressources materielles; 

♦ I'echeancier du projet; 

♦ I’organigramme des ressources ; 

♦ les besoins en ressources; 

♦ le registre des risques. 

5.8.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de 
ce processus figurent, entre autres : 

♦ le plan de gestion des ressources; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 

5.8.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les affectations des ressources materielles; 

♦ I’organigramme des ressources ; 

♦ le registre des risques. 
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5.9 MAITRISER LES COMMUNICATIONS 


MaTtriser les communications est le processus qui consiste a satisfaire les besoins en information du projet et de ses 
parties prenantes. L’interet principal de ce processus reside dans leflux d'information optimal, tel que defini dans le plan 
de gestion de la communication et le plan d’engagement des parties prenantes. Ce processus est execute tout au long 
du projet. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-10. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

V___ ) 


Donnees de sortie 


.1 Informations sur 

la performance d'execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

--- J 


Figure 5-10. Maitriser les communications: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 

5.9.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

5.9.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les communications du projet. 
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5.9.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 


5.9.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des parties prenantes. 


5.10 MAITRISER LES RISQUES 

MaTtriser les risques est le processus qui consiste a suivre la mise en oeuvre des plans de reponse aux risques 
convenus, a faire le suivi des risques identifies, a identifier de nouveaux risques, a les analyser et a evaluer I’efficacite 
du processus de gestion des risques tout au long du projet. L’interet principal de ce processus est qu’il permet de fonder 
les decisions du projet sur les informations actuelles concernant I’exposition au risque global du projet et les risques 
individuels du projet. Ce processus est execute tout au long du projet. Les donnees d’entree et de sortie de ce processus 
sont representees sur la figure 5-11. 


Donnees d’entree V Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d'execution 

.4 Rapports sur la performance 
d'execution 

V_ 


.1 Informations sur 

la performance d’execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

.5 Mises a jour des actifs 
organisationnels 

v _y 


Figure 5-11. MaTtriser les risques: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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5.10.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 


Le plan de gestion des risques est I’un des composants du plan de management du projet susceptibles de constituer 
des donnees d’entree de ce processus. 


5.10.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 

5.10.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent etre mis a jour a la suite de ce processus. 


5.10.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des hypotheses ; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 


5.11 MAITRISER LES APPROVISIONNEMENTS 

MaTtriser les approvisionnements est le processus qui consiste a gerer les relations fournisseurs, a suivre I’execution 
du contrat, a effectuer les changements et corrections appropries, et a conclure des contrats. L’interet principal de ce 
processus est qu'il permet de s'assurer que les performances du fournisseur et de I'acheteur satisfont les exigences 
du projet, conformement aux accords juridiques. Ce processus est execute tout au long du projet, lorsque les 
approvisionnements sont actifs. Les donnees d’entree et de sortie de ce processus sont representees sur la figure 5-12. 
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Donnees d’entree 


Donnees de sortie 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Accords 

.4 Documents d'approvisionnements 
.5 Demandes de changement 


.1 Approvisionnements clos 
.2 Informations sur 


la performance d’execution 
.3 Mises a jour des documents 


d'approvisionnements 
.4 Demandes de changement 
.5 Mises a jour du plan 


approuvees 

.6 Donnees de performance 


d'execution 

.7 Facteurs environnementaux 


de management du projet 
.6 Mises a jour des documents 


de i'organisation 
.8 Actifs organisationnels 


du projet 

.7 Mises a jour des actifs 


V 


J organisationnels 


V 


Figure 5-12. Maitriser les approvisionnements: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 

5.11.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des exigences ; 

♦ le plan de gestion des risques ; 

♦ le plan de gestion des approvisionnements ; 

♦ le plan de gestion des changements ; 

♦ la reference de base de I’echeancier. 

5.11.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ les rapports qualite; 

♦ la documentation des exigences ; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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5.11.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des risques ; 

♦ le plan de gestion des approvisionnements ; 

♦ la reference de base de I’echeancier; 

♦ la reference de base des couts. 


5.11.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d'etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le registre des retours d’experience; 

♦ les besoins en ressources; 

♦ la matrice de tragabilite des exigences ; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 

5.12 MAITRISER L’ENGAGEMENT DES PARTIES PRENANTES 

MaTtriser I’engagement des parties prenantes est le processus qui consiste a suivre les relations avec les parties 
prenantes du projet et a adapter les strategies afin d’encourager leur engagement grace au changement des plans 
et des strategies d’engagement. L’interet principal de ce processus est qu’il permet de maintenir ou de renforcer 
I’efficience et I’efficacite des activites d’engagement des parties prenantes au fur et a mesure que le projet et son 
environnement evoluent. Ce processus est execute tout au long du projet. Les donnees d'entree et de sortie de ce 
processus sont representees sur la figure 5-13. 


Donnees d’entree 


.1 Plan de management du projet 
.2 Documents du projet 
.3 Donnees de performance 
d’execution 

.4 Facteurs environnementaux 
de I'organisation 
.5 Actifs organisationnels 

v___y 


Donnees de sortie 


.1 Informations sur 

la performance d’execution 
.2 Demandes de changement 
.3 Mises a jour du plan 
de management du projet 
.4 Mises a jour des documents 
du projet 

-_- / 


Figure 5-13. Maitriser i’engagement des parties prenantes: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 
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5.12.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Parmi les composants du plan de management du projet susceptibles de constituer des donnees d’entree pour ce 
processus, figurent notamment: 

♦ le plan de gestion des ressources; 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

5.12.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ les communications du projet; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 

5.12.3 MISES A JOUR DU PLAN DE MANAGEMENT DU PROJET 

Les composants du plan de management du projet susceptibles d’etre mis a jour a la suite de I'execution de ce 
processus sont, entre autres : 

♦ le plan de gestion des ressources; 

♦ le plan de gestion de la communication ; 

♦ le plan d’engagement des parties prenantes. 

5.12.4 MISES A JOUR DES DOCUMENTS DU PROJET 

Parmi les documents du projet susceptibles d’etre mis a jour a la suite de ce processus, figurent notamment les 
elements suivants: 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ le registre des risques ; 

♦ le registre des parties prenantes. 
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GROUPE DE PROCESSUS DE CLOTURE 

Le groupe de processus de cloture comprend le(s) processus permettant de realiser ou de clore formellement un 
projet, une phase ou un contrat. Ce groupe de processus verifie que les processus definis sont acheves pour tous les 
groupes de processus, afin de clore le projet ou une phase du projet, selon le cas, et etablit formellement la fin du projet 
ou de la phase. L’interet principal de ce groupe de processus est que les phases, projets et contrats sont clotures de 
maniere appropriee. Bien qu’il n’existe qu’un seul processus dans ce groupe de processus, les organisations peuvent 
avoir associe leurs propres processus a la cloture d'un projet, d’une phase ou d’un contrat. Par consequent, le terme 
«groupe de processus» est conserve. 

Ce groupe de processus peut egalement gerer la cloture anticipee du projet, par exemple des projets avortes 
ou annules. 

Le groupe de processus de cloture (figure 6-1) inclut les processus de management de projet recenses a la 
section 6.1. 



La fleche circulaire en pointilles indique que le processus fait 
partie du domaine de connaissance en gestion de (’integration 
du projet. Ce domaine de connaissance coordonne et unifie 
les processus a partir des autres domaines de connaissance. 


Figure 6-1. Groupe de processus de cloture 
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6.1 CLORE LE PROJET OU LA PHASE 


Clore le projet ou la phase est le processus de finalisation de toutes les activites d’un projet, d’une phase ou d’un 
contrat. L’interet principal de ce processus est que les informations du projet ou de la phase sont archivees, le travail 
prevu est acheve et les ressources organisationnelles sont liberees afin de mener d’autres projets. Ce processus est 
execute une fois ou a des moments predefinis dans le cadre du projet. Les donnees d’entree et de sortie de ce processus 
sont representees sur la figure 6-2. 


Donnees d’entree 


.1 Charte du projet 

.2 Plan de management du projet 

.3 Documents du projet 

.4 Livrables acceptes 

.5 Documents business 

.6 Accords 

.7 Documents d'approvisionnements 
.8 Actifs organisationnels 
V_I_/ 


Donnees de sortie 


.1 Mises a jour des documents 
du projet 

.2 Transfert du produit, 

du service ou du resultat final 
.3 Rapport final 
.4 Mises a jour des actifs 
organisationnels 

V _ 


Figure 6-2. Clore le projet ou la phase: donnees d’entree et donnees de sortie 


Les besoins du projet determined les composants du plan de management du projet et les documents necessaires. 


6.1.1 COMPOSANTS DU PLAN DE MANAGEMENT DU PROJET 

Tous les composants du plan de management du projet peuvent constituer des donnees d’entree pour ce processus. 
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6.1.2 EXEMPLES DE DOCUMENTS DE PROJET 

Certains documents du projet peuvent constituer des donnees d’entree pour ce processus, notamment: 

♦ le journal des hypotheses ; 

♦ la base des estimations ; 

♦ le journal des changements; 

♦ le journal des points a traiter; 

♦ le registre des retours d’experience; 

♦ la liste des jalons ; 

♦ les communications du projet; 

♦ les mesures de controle de la qualite; 

♦ les rapports qualite; 

♦ la documentation des exigences ; 

♦ le registre des risques ; 

♦ le rapport sur les risques. 

6.1.3 MISES A JOUR DES DOCUMENTS DU PROJET 

Le registre des retours d’experience est I’un des documents de projet susceptibles d’etre mis a jour a la suite de 
ce processus. 
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ANNEXE XI 

CHANGEMENTS APPORTES A LA SIXIEME EDITION 


Cette annexe a pour objet de donner une vue d’ensemble des changements apportes au Guide du Corpus des 
corinaissances en management de projet (Guide PMBOK®) — Cinquieme edition en vue de creer le Guide PMBOK ®— 
Sixieme edition. 


XI.1 PERIMETRE DE LA MISE A JOUR 

Le perimetre approuve pour le Guide PMBOK® —Sixieme edition inclut les elements suivants : 

♦ Revoir les elements ci-dessous, determiner si le materiel fera partie ou non des nouvelles editions et suivre 
la disposition: 

■ Tout le materiel relatif aux sections 1 a 13, a I'annexe A1 et au glossaire, qui a ete reporte au cours de 
I’elaboration d’un Guide du Corpus des connaissances en management de projet (Guide PMBOK ®)— 
Cinquieme edition. 

■ L’ensemble des commentaires et des retours d’information relatifs aux sections 1 a 13, a I’annexe A1 et au 
glossaire d’un Guide du Corpus des connaissances en management de projet (Guide PMBOK®) —Cinquieme 
edition, qui ont ete regus par PMI depuis les premiers developpement et publication. 

♦ Revoir, interpreter et garantir la conformite avec la norme ISO 21500 dans le cadre de I’elaboration du standard. 

♦ Garantir I’harmonisation avec tout autre standard de base de PMI. 

♦ Analyser les resultats de I’etude portant sur la definition du role du chef de projet et les autres etudes de 
recherche de PMI afin de les integrer au besoin. 

♦ Passer en revue, mener et analyser les recherches, en particulier les ajouts, les suppressions et les changements 
importants concernant la Sixieme edition et eventuellement les donnees d’entree strategies pour les 
prochaines editions. 

Dans cet esprit, I’equipe de mise a jour a axe ses efforts sur le renforcement de la coherence et de la clarte en 
peaufinant et en standardisant les processus, les donnees d’entree, les outils, les techniques et les donnees de sortie. 
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XI .2 REGLES RELATIVES A L’HARMONISATION ENTRE LES TERMES DU GLOSSAIRE ET 
LE LEXIQUE PMIDES TERMES LIES AU MANAGEMENT DE PRO JET 


Afin de garantir que les termes utilises dans le Guide PMBOK® concordent avec les termes du Lexique PMI du 
management de projet 1 et sont conformes aux autres standards pertinents de PMI, la Sixieme edition a suivi les 
regies suivantes: 

♦ Pour les termes figurant a la fois dans le Guide PMBOK® et dans le Lexique PMI , on utilise la definition du 
Lexique PMI. 

♦ Lorsque des termes utilises dans le Guide PMBOK®, absents du Lexique PMI, figurent dans d’autres standards 
pertinents de PMI, les definitions des termes doivent etre identiques. Si les definitions ne sont pas conformes 
aux standards correspondants, le terme est communique a I'equipe en charge du Lexique PMI afin qu’elle aide a 
creer une definition commune acceptable. 


XI .3 REGLES RELATIVES AU TRAITEMENT DES DONNEES D’ENTREE ET DES DONNEES 
DE SORTIE 

Les regies d'entreprise suivantes ont ete utilisees pour garantir la coherence dans I'ordre et les informations au sein 
des donnees d’entree et des donnees de sortie pour chacun des processus de management de projet: 

♦ Regies fondamentales: 

■ Les donnees d’entree designent les documents essentiels au processus. 

■ La donnee de sortie doit devenir une donnee d’entree d’un autre processus de management de projet a 
moins qu’il ne s’agisse d’une donnee de sortie terminale ou qu’elle soit integree a une autre donnee d’entree, 
comme les documents de projet. 

■ Les donnees d’entree doivent provenir d’une donnee de sortie d’un autre processus de management de projet 
a moins qu’elle ne provienne de I'exterieur du projet. 

♦ Regies relatives aux documents du projet: 

■ Lorsque des documents de projet specifiques sont identifies la premiere fois, ils sont repertories comme une 
donnee de sortie specifique. Ensuite, ils sont repertories comme des«mises a jour des documents du projet» 
dans la liste des donnees de sortie, et decrits dans la section narrative. 

■ Lorsqu’un document du projet est une donnee d’entree, le terme « documents du projet» est utilise et les 
documents du projet specifiques sont decrits dans la section narrative. 

♦ Regies relatives au plan de management du projet: 

■ Pour les processus de planification qui creent un plan subsidiaire, la charte du projet est la premiere donnee 
d’entree et le plan de management du projet est la seconde donnee d’entree. 

■ Le processus qui cree un composant du plan de management du projet enumere specifiquement les 
composants. Les composants sont ensuite repertories comme des«mises a jour du plan de management du 
projet»dans la liste des donnees de sortie, et decrits dans la section narrative. 

■ Lorsque le plan de management du projet serf de donnee d’entree au processus, les composants specifiques 
de ce plan qui peuvent eventuellement etre pris en compte sont decrits dans la section narrative. 


'Project Management Institute. 2016. The PMI Lexicon of Project Management Terms. Available from 
http://www.pmi.org/Lexiconterms 
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♦ Regies relatives a I’organisation en seguences: 

■ Si la charte du projet est une donnee d’entree, c’est la premiere donnee d’entree. 

■ Lorsque le plan de management du projet est une donnee d’entree ou une donnee de sortie, les plans de 
management de projet subsidiaires sont enumeres dans I’ordre des sections dans le Guide PMBOK®ou ils 
sont produits en tant que donnee de sortie, suivis par les references de base, puis tout autre plan. 

■ Les documents du projet sont enumeres par ordre alphabetique. 

■ Les facteurs environnementaux de I’organisation et les actifs organisationnels sont recenses en dernier dans 
cet ordre. 

■ Lorsque des mises a jour constituent une donnee de sortie, elles sont enumerees dans I'ordre suivant: 
o Mises a jour du plan de management du projet 

o Mises a jour des documents du projet 
o Mises a jour des actifs organisationnels. 

XI .4 REGLES RELATIVES A LA MANIPULATION DES OUTILS ET DES TECHNIQUES 

La Sixieme edition s’est efforcee de reduire le nombre d’outils et de techniques en ciblant ceux qui sont actuellement 
utilises sur la majorite des projets la plupart du temps. Plusieurs outils et techniques ont ete elimines sur la base 
d’etudes de marche et de recherches universitaires. Afin de limiter les repetitions, un outil ou une technique est decrit(e) 
la premiere fois qu’il/elle est repertorie(e). Les processus ulterieurs qui utilisent cet outil ou cette technique renvoient a 
la description precedente. 

La Sixieme edition a regroupe quelques-uns des outils et techniques couramment utilises en fonction de leur objectif. 
Tous les outils et techniques ne relevent pas d’un groupe. Cependant, pour les outils ou les techniques qui font partie 
d’un groupe, ce groupe est liste, puis les exemples des outils et des techniques qu’il contient sont decrits dans la section 
narrative. Les groupes d’outils et de techniques sont les suivants : 

♦ collecte des donnees ; 

♦ analyse des donnees; 

♦ representation des donnees; 

♦ prise de decision ; 

♦ competences en communication ; 

♦ competences interpersonnelles et d’equipe. 

L’annexe X6 recense I’ensemble des outils et techniques dans le Guide PMBOK® par groupe, le cas echeant, et 
enumere les processus lorsqu’ils sont utilises. 
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XI .5 PLAN DE MANAGEMENT DU PRO JET 


Tous les composants du plan de management de projet ne sont pas crees dans le cadre d’un processus distinct. Ces 
composants sont censes etre crees dans le cadre du processus Elaborer le plan de management du projet. Ms incluent 
notamment le plan de gestion des changements, le plan de gestion de la configuration, la reference de base de la 
performance, le cycle de vie du projet, I’approche de developpement et les revues de performance. 


XI .6 SECTION 1—INTRODUCTION 

La section Introduction a ete considerablement remaniee. Les informations introductives sur les projets, les 
programmes et les portefeuilles conformes aux autres standards de base de PMI demeurent. Cependant, il y a de 
nouvelles informations sur les cycles de vie du developpement et du projet, les phases du projet et les sorties de 
phase. Ces informations donnent un apergu tres complet pour la selection des approches de developpement (predictive, 
iterative, incremental et adaptative), en fonction de la nature du projet. Parmi les nouvelles informations concernant les 
documents business, on peut notamment citer le business case et le plan de gestion des benefices. 


XI .7 SECTION 2—L’ENVIRONNEMENT DANS LEQUEL LES PROJETS SONT EXECUTES 

Le contenu de la section 2 a ete considerablement remanie. Les informations relatives aux actifs organisationnels et 
aux facteurs environnementaux de (’organisation demeurent. Cependant, il y a un nouveau contenu sur la gouvernance, 
les elements de management et les types de structures organisationnelles. 


XI .8 SECTION 3—LE ROLE DU CHEF DE PRO JET 

Cette nouvelle section decrit le role du chef de projet dans I’equipe. Elle comprend des informations sur la sphere 
d’influence et les competences du chef de projet. Le Talent Triangle® de PMI est examine, notamment I’attention 
accordee aux competences strategies et en management d’entreprise, aux competences en management de projets 
techniques et aux competences en leadership. Les styles de leadership et la personnalite sont egalement abordes dans 
le cadre de cette section. La fin de cette section est axee sur le role d’integrateur du chef de projet. 


XI .9 AGILE 

Depuis la cinquieme edition du Guide PMBOK®, un plus grand nombre de methodologies agiles et adaptatives ont 
ete adoptees dans a gestion des projets. La sixieme edition a inclus une sous-section intitulee Considerations relatives 
aux environnements adaptatifs au debut des sections 4 a 13. Quelques outils et techniques agiles specifies ont 
ete integres au Guide PMBOK 0 , tels que la planification d'iterations ou de sprint. L’annexe X3 decrit I’utilisation des 
approches agile, adaptative, iterative et hybride du point de vue des groupes de processus de management de projet. 
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XI.10 SUPPORT DE COUVERTURE DES DOMAINES DE CONNAISSANCES 


Chaque section Domaine de connaissance comprend des supports standardises avant la presentation du premier 
processus. Les supports sont presentes dans les sous-sections suivantes : 

♦ Principaux concepts. Les principaux concepts associes au domaine de connaissance specifique y sont reunis. 
Ces informations ont ete presentees dans les editions precedentes; dans cette edition, elles sont regroupees et 
presentees a des fins de coherence entre les domaines de connaissance. Ces principaux concepts sont compiles 
dans I'annexe X4. 

♦ Tendances et pratiques emergentes. La profession du chef de projet continue d’evoluer. Cependant, le but du 
Guide PMBOK® n’est pas de diriger I’industrie mais de decrire ce qui est considere comme une bonne pratique 
dans la majorite des projets la plupart du temps. Cette sous-section identifie quelques-unes des tendances ou 
des pratiques emergentes qui apparaissent, mais non utilisees dans la majorite des projets. 

♦ Considerations relatives a I’adaptation. La sixieme edition souligne I’importance d’adapter tous les aspects 
du projet afin de repondre aux besoins de I'organisation, de I'environnement, des parties prenantes et d'autres 
variables. Cette sous-section identifie les domaines que le chef de projet peut prendre en compte lorsqu’il adapte 
son projet. Ces considerations relatives a I’adaptation sont compilees dans I’annexe X5. 

♦ Considerations relatives aux environnements agiies/adaptatifs. Cette sous-section identifie quelques-unes 
des domaines ou les approches adaptatives peuvent differer des approches predictives dans le domaine de 
connaissance particulier. 


XI. 11 CHANGEMENTS APPORTES AUX DOMAINES DE CONNAISSANCE ET AUX PROCESSUS 

Deux noms de domaines de connaissance ont ete changes afin de mieux refleter le travail effectue. 

♦ «Management des delais du projet»a ete remplace par«Gestion de I'echeancier du projet»afin d'illustrer le fait 
que I'echeancier du projet est defini et gere au cours du projet, tandis que le temps n’est pas gere. 

♦ Les ressources a la fois humaines et materielles sont traitees dans la sixieme edition. Ainsi, le domaine de 
connaissance« Management des ressources humaines de projet»a ete remplace par«Gestion des ressources 
du projet». 

Un processus a ete supprime et trois nouveaux processus ont ete ajoutes, afin de refleter les changements dans la 
fagon dont les projets sont geres dans la pratique. Un processus a ete deplace entre les domaines de connaissance. Ces 
changements sont recapitules ci-apres, et examines dans la section Domaine de connaissance pertinente : 

♦ Gerer les connaissances du projet (section 4.4): ajoutee. 

♦ Estimer les ressources necessaires aux activites (section 6.4): deplacee vers Gestion des ressources du projet. 

♦ MaTtriser les ressources (section 9.6): ajoutee. 

♦ Executer les reponses aux risques (section 11.6): ajoutee. 

♦ Clore les approvisionnements (section 12.4): supprimee. 
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Plusieurs noms de processus ont ete changes afin de renforcer la coherence entre les processus et d’ameliorer la 
clarte. Les recherches indiquent que les chefs de projet ont essentiellement tendance a maitriser, faciliter et gerer plutot 
que controler, en particulier dans les processus qui impliquent des interactions entre les personnes. Par consequent, 
les noms des processus « Control Communications»,«Control Risks » et« Control Stakeholder Engagement»ont ete 
modifies dans la version anglaise (originale). Neanmoins dans la version frangaise ces noms de processus Martriser les 
communications, Martriser les risques et Martriser I'engagement des parties prenantes ont ete conserves. La liste ci- 
dessous reprend tous les changements apportes aux noms de processus : 

♦ Mettre en oeuvre I’assurance qualite (section 8.2): remplace par Gerer la qualite. 

♦ Planifier le management des ressources humaines (section 9.1): remplace par Planifier la gestion des ressources. 

♦ Constituer I’equipe de projet (section 9.2): remplace par Obtenir les ressources. 

♦ Developper Pequipe de projet (section 9.3): remplace par Developper I'equipe. 

♦ Diriger I’equipe de projet (section 9.4): remplace par Gerer I’equipe. 

♦ Dans la version originale anglaise (section 10.3), le nom du processus a ete change de«Control Communications» 
en« Monitor Communications». Neanmoins, il reste Maitriser les risques en frangais. 

♦ Dans la version originale anglaise (section 11.6), le nom du processus a ete change de « Control Risks » en « 
Monitor Risks». Neanmoins, il reste Maitriser les risques en frangais. 

♦ Planifier le management des parties prenantes (section 13.2) : remplace par Planifier I’engagement des 
parties prenantes. 

♦ Dans la version originale anglaise (section 13.4), le nom du processus a ete change de « Control Stakeholder 
Engagement» en « Monitor Stakeholder Engagement». Neanmoins, il reste Martriser I’engagement des parties 
prenantes en frangais. 


XI .12 SECTION 4—CHANGEMENTS APPORTES A LA GESTION DE L’INTEGRATION DU PRO JET 

Un nouveau processus, Gerer les connaissances du projet, a ete ajoute. C’est le resultat de nombreux commentaires 
differes de la cinquieme edition exprimant la necessite de traiter la gestion des connaissances dans les projets. Une 
donnee de sortie essentielle de ce processus est le registre des retours d’experience. Ce registre est utilise au cours de 
nombreux processus de la sixieme edition. II met en avant la necessite d'apprendre sans cesse tout au long du projet 
au lieu d’attendre la fin pour reflechir. 

Les documents business sont des donnees d’entree pour les processus Elaborer la charte du projet et Clore le 
projet ou la phase. L’introduction des documents business met en evidence I’importance de rester en harmonie avec le 
business case et la gestion des benefices tout au long du projet. Les activites administratives concernant la cloture des 
approvisionnements ont ete integrees au processus Clore le projet ou la phase. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-1 
recapitule les processus de la section 4 : 
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Tableau XI-1 Changements apportes a la section 4 


Processus de la cinquieme edition 

Processus de la sixieme edition 

4.1 Elaborer la charte du projet 

4.1 Elaborer la charte du projet 

4.2 Elaborer le plan de management du projet 

4.2 Elaborer le plan de management du projet 

4.3 Diriger et gerer le travail du projet 

4.3 Diriger et gerer le travail du projet 

4.4 Surveiller et maTtriser le travail du projet 

4.4 Gerer les connaissances du projet 

4.5 Mettre en oeuvre la maTtrise integree 
des modifications 

4.5 MaTtriser le travail du projet 

4.6 Clore le projet ou la phase 

4.6 MaTtriser les changements 


4.7 Clore le projet ou la phase 


XI .13 SECTION 5—CHANGEMENTS APPORTES A LA GESTION DU PERIMETRE DU PRO JET 

L’equipe de la sixieme edition a collabore avec The Standard for Business Analysis at in de garantir I’harmonisation des 
deux standards de base, sans qu’ils ne fassent double emploi. II n’a pas ete necessaire de changer les noms des processus. 

Les changements relatifs aux informations decrites aux sections XI .1 a XI .11 ont ete appliques. 


XI .14 SECTION 6—CHANGEMENTS APPORTES A LA GESTION DE L’ECHEANCIER DU PRO JET 

La section 6 auparavant intitulee Management des delais du projet a ete renommee Gestion de I’echeancier du projet. 
Les recherches ont indique un soutien en faveur de ce changement de nom du etant donne que les chefs de projet ne 
gerent pas le temps mais aussi definissent et gerent I'echeancier du projet. En raison d’une reorientation et du fait que 
le processus Management des ressources humaines du projet ait ete renomme Gestion des ressources du projet, le 
processus Estimer les ressources necessaires aux activites a ete deplace de ce domaine de connaissance vers Gestion 
des ressources du projet. Certains concepts agiles ont ete integres au processus Elaborer I’echeancier. Les figures et les 
textes associes ont ete mis a jour afin de clarifier les concepts de planification abordes dans la section. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-2 
recapitule les processus de la section 6 : 
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Tableau XI-2 Changements apportes a la section 6 


Processus de la cinquieme edition 

Processus de la sixieme edition 

6.1 Planifier le management de I’echeancier 

6.1 Planifier la gestion de I’echeancier 

6.2 Definir les activites 

6.2 Definir les activites 

6.3 Organiser les activites en sequence 

6.3 Organiser les activites en sequence 

6.4 Estimer les ressources necessaires 
aux activites 

6.4 Estimer la duree des activites 

6.5 Estimer la duree des activites 

6.5 Elaborer I’echeancier 

6.6 Elaborer I’echeancier 

6.6 MaTtriser I’echeancier 

6.7 MaTtriser I’echeancier 



XI.15 SECTION 7—CHANGEMENTS APPORTES A LA GESTION DES COUTS DU PROJET 

Les changements relatifs aux informations decrites aux sections XI .1 a XI .11 ont ete appliques. 


XI .16 SECTION 8—CHANGEMENTS APPORTES A LA GESTION DE LA QUALITE DU PRO JET 

Des recherches universitaires et des etudes de marche ont ete menees concernant le processus Mettre en oeuvre 
I’assurance qualite. Les recherches ont indique que nombre des outils et techniques lies a la qualite, precedemment 
recenses, ne sont pas beaucoup utilises dans les projets actuels. La profession se concentre davantage sur la gestion de 
la qualite grace au plan de gestion de la qualite. Ainsi, le processus Mettre en oeuvre I'assurance qualite a ete reoriente 
et son nom a ete remplace par Gerer la qualite. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-3 
recapitule les processus de la section 8 : 


Tableau XI-3 Changements apportes a la section 8 


Processus de la cinquieme edition 

Processus de la sixieme edition 

8.1 Planifier le management de la qualite 

8.1 Planifier la gestion de la qualite 

8.2 Mettre en oeuvre I’assurance qualite 

8.2 Gerer la qualite 

8.3 Mettre en oeuvre le controle qualite 

8.3 MaTtriser la qualite 


646 


Troisieme partie - Annexe XI 

















XI .17 SECTION 9—CHANGEMENTS APPORTES A LA GESTION DES RESSOURCES DU PRO JET 


La sixieme edition a etendu le perimetre de cette section; precedemment axee sur les ressources humaines, elle inclut 
desormais toutes les ressources. Afin de faire la distinction entre les ressources humaines et les autres ressources, le 
terme«ressources de I'equipe»est utilise pour designer les ressources humaines, et le terme«ressources physiques» 
est utilise pour designer les autres ressources. Le processus Estimer les ressources necessaires aux activites a ete 
transfere dans ce domaine de connaissance a partir du processus Gestion de I’echeancier du projet, et un nouveau 
processus MaTtriser les ressources a ete ajoute. Le mot« projet» a ete supprime de Developper I’equipe et Gerer 
I’equipe : on presume que la seule equipe que doit developper et gerer le chef de projet est I’equipe projet. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-4 
recapitule les processus de la section 9 : 


Tableau XI-4 Changements apportes a la section 9 


Processus de la cinquieme edition 

Processus de la sixieme edition 

9.1 Planifier le management des 
ressources humaines 

9.1 Planifier la gestion des ressources 

9.2 Constituer I’equipe de projet 

9.2 Estimer les ressources necessaires 
aux activites 

9.3 Developper I’equipe de projet 

9.3 Obtenir les ressources 

9.4 Diriger I’equipe de projet 

9.4 Developper I’equipe 


9.5 Gerer I’equipe 


9.6 MaTtriser les ressources 


XI .18 SECTION 10—CHANGEMENTS APPORTES A LA GESTION DES COMMUNICATIONS 
DU PROJET 

Une distinction subtile mais importante a ete faite dans cette section en ce qui concerne la communication du projet. 
Le terme«communication»indique le fait de communiques par exemple organiser une reunion, donner des informations 
et ecouter activement. Le terme « communication » indique les elements de la communication, comme les notes, 
les presentations et les e-mails. Dans la version anglaise (originale), le nom du processus a ete change de « Control 
Communications»en« Monitor Communications». Neanmoins, il reste MaTtriser les communications en frangais. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-5 
recapitule les processus de la section 10 : 
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Tableau XI-5 Changements apportes a la section 10 


Processus de la cinquieme edition 

Processus de la sixieme edition 

10.1 Planifier le management des communications 

10.1 Planifier la gestion des communications 

10.2 Gerer les communications 

10.2 Gerer les communications 

10.3 MaTtriser les communications 

10.3 MaTtriser les communications 


XI .19 SECTION 11—CHANGEMENTS APPORTES A LA GESTION DES RISQUES DU PROJET 

Une attention accrue a ete accordee au risque global du projet dans I'ensemble des processus de gestion des risques. 
Un nouveau processus, Executer les reponses aux risques, a ete ajoute. Ce processus fait partie du groupe de processus 
d’execution. Le nouveau processus souligne I'importance de ne pas simplement planifier les reponses aux risques, 
mais egalement de les executer. Une nouvelle«escalade»des reponses aux risques a ete mise en place pour indiquer 
que, si des risques exterieurs au perimetre des objectifs du projet ont ete identifies, ils doivent etre communiques a la 
personne ou division competente au sein de I'organisation. Dans la mesure ou les risques sont des evenements ou des 
conditions futurs incertains, ils ne peuvent etre controles. Cependant, ils peuvent etre martrises. Dans la version anglaise 
(originale), le nom du processus a ete change de « Control Risks » en « Monitor Risks ». Neanmoins, il reste MaTtriser 
les risques en frangais. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-6 
recapitule les processus de la section 11 : 

Tableau XI-6 Changements apportes a la section 11 


Processus de la cinquieme edition 

’ 

Processus de la sixieme edition 

11.1 Planifier le management des risques 

11.1 Planifier la gestion des risques 

11.2 Identifier les risques 

11.2 Identifier les risques 

11.3 Mettre en oeuvre I’analyse qualitative 
des risques 

11.3 Effectuer I’analyse qualitative des risques 

11.4 Mettre en oeuvre I’analyse quantitative 
des risques 

11.4 Effectuer I’analyse quantitative des risques 

11.5 Planifier les reponses aux risques 

11.5 Planifier les reponses aux risques 

11.6 MaTtriser les risques 

11.6 Executer les reponses aux risques 


11.7 MaTtriser les risques 
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XI .20 SECTION 12—CHANGEMENTS APPORTESALAGESTION DES APPROVISIONNEMENTS 
DU PROJET 


Beaucoup d’informations de ce domaine de connaissance ont ete mises a jour afin de refleter une perspective plus 
globale. De nombreux projets sont menes en collaboration avec des parties prenantes dans differents pays ou par des 
organisations preserves dans plusieurs pays. 

Comme le montrent les etudes de marche, rares sont les chefs de projet qui, dans la pratique, cloturent les 
approvisionnements. En general, une personne au sein des services juridiques, en charge des contrats ou des 
approvisionnements, a ce pouvoir. Par consequent, les informations du processus Clore les approvisionnements 
concernant devaluation de tous les livrables acheves et leur comparaison avec le contrat ont ete integrees dans MaTtriser 
les approvisionnements. Les informations sur les aspects administratifs, les communications et les documents ont ete 
deplacees vers Clore le projet ou la phase. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-7 
recapitule les processus de la section 12 : 

Tableau XI-7 Changements apportes a la section 12 


Processus de la cinquieme edition 

Processus de la sixieme edition 

12.1 Planifier le management des 
approvisionnements 

12.1 Planifier la gestion des approvisionnements 

12.2 Proceder aux approvisionnements 

12.2 Proceder aux approvisionnements 

12.3 MaTtriser les approvisionnements 

12.3 MaTtriser les approvisionnements 

12.4 Clore les approvisionnements 
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XI .21 SECTION 13—CHANGEMENTS APPORTES A LA GESTION DES PARTIES PRENANTES 
DU PROJET 


Tout en poursuivant les recherches et la pratique actuelles, une nouvelle orientation a ete prise afin de cibler non plus 
la gestion des parties prenantes mais leur engagement. Dans la version anglaise (originale), le nom du processus a ete 
change de« Control Stakeholder Engagement» en « Monitor Stakeholder Engagement». Neanmoins, il reste MaTtriser 
I’engagement des parties prenantes en frangais. 

Les changements relatifs aux informations decrites aux sections XI.1 a XI.11 ont ete appliques. Le tableau XI-8 
recapitule les processus de la section 13 : 


Tableau XI-8 Changements apportes a la section 13 


Processus de la cinquieme edition 

Processus de la sixieme edition 

13.1 Identifier les parties prenantes 

13.1 Identifier les parties prenantes 

13.2 Planifier le management des 
parties prenantes 

13.2 Planifier I’engagement des 
parties prenantes 

13.3 Gerer I’engagement des 
parties prenantes 

13.3 Gerer I’engagement des 
parties prenantes 

13.4 MaTtriser I’engagement des 
parties prenantes 

13.4 MaTtriser I’engagement des 
parties prenantes 


XI .22 GLOSSAIRE 

Le glossaire du Guide PMBOK ® — Sixieme edition a ete mis a jour afin de clarifier la signification mais aussi 
d’ameliorer la qualite et la precision de toutes les traductions. Les termes qui ne sont pas utilises dans la sixieme edition, 
ou dont le sens ne differe pas de leur usage usuel, ont ete elimines. 
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ANNEXE X2 

CONTRIBUTEURS ET REVISEURS 

DE LA SIXIEME EDITION DU PMBOK® GUIDE 


Des volontaires du PMI ont d’abord tente de codifier le corpus des connaissances en management de projet dans 
le Rapport special sur I’ethique, les standards et /’accreditation, publie en 1983. Depuis, d’autres volontaires ont pris 
I’initiative de mettre a jour et d’ameliorer ce document original. Ms contribuent a ce standard mondialement reconnu en 
matiere de management de projet, le Guide du corpus des connaissances en management de projet (Guide PMBOK 0 ) 
du PMI. La presente annexe enumere les personnes qui ont participe a I'elaboration et la production de la Sixieme 
edition du Guide PMBOK 0 . Aucune liste ne peut representer correctement toutes les contributions des volontaires qui 
ont participe a I’elaboration de la Sixieme edition du Guide PMBOK 0 . 

Le Project Management Institute remercie toutes ces personnes pour leur soutien et salue leurs contributions au 
domaine du management de projet. 


X2.1 COMITE PRINCIPAL DE LA SIXIEME EDITION DU PMBOK ® GUIDE 

Les personnes ci-dessous ont ete membres du comite principal de projet, a titre de contributeurs a des textes ou 
concepts et de responsables : 

Cyndi Snyder Dionisio, MBA, PMP, Presidente 

David A. Hillson, PhD, PMI Fellow, HonFAPM, Vice-president (responsable de I’engagement des volontaires 
et responsable de la section 11) 

Lynda Bourne, DPM, FACS (responsable des sections 10 et 13) 

Larkland A. Brown, PMP, PMI-ACP (responsable de la section 6) 

Pan C.P. Kao, PhD, PMP, (responsable des sections 7 et 12) 

Mercedes Martinez Sanz, PMP (responsable de la section 4) 

Alejandro Romero-Torres, PhD, PMP, (responsable de la gestion et la qualite des documents et responsable 
de la section 5) 

Guy Schleffer, PfMP, PMP, (responsable des sections 8 et 9) 

Michael J. Stratton, PhD, PMP, (responsable des sections 1,2 et 3)f 

Kristin L. Vitello, Specialiste des projets de standards 

Gwen Whitman, EMBA, PfMP (responsable communication du projet) 


tDecede. Le comite principal et le PMI saluent le travail de Michael J. Stratton sur la Sixieme edition du Guide 
PMBOK 0 . M. Stratton etait devoue a la profession, et son travail temoigne de ses contributions au domaine du 
management de projet. 
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X2.2 CONTRIBUTEURS IMPORTANTS 


Outre les membres du comite principal de projet, les personnes suivantes ont apporte des donnees d’entree ou 
des concepts importants: 

Ernest Baker, PMP, professionnel PRINCE2® 

Cheryl Burcham, PMP 

Guido Caciagli, B., PMP 

Jimmy I. Char, PMP, SDI 

Catalin-Teodor Dogaru, PhD, MBA 

Andres Falcon, PMP 

Anna Maria Felici, PMP 

Eren Gokce, MBA, PMP 

Pamela S. Goodhue, MBA, PMP 

Franco R. Graziano, MPA, PMP 

Joy Gumz, CPA, PMP 

Salah M. Haswah, PMP, PgMP 

Puja Kasariya, PMP 

Srikanth Krishnamoorthy, PMP, PGDSA 

Tom Magee, MBA, PMP 

David A. Maynard, MBA, PMP 

Bob Mahler, PMP, PMI-RMP 

Frank R. Parth, MBA, PMP 

DattatrayaY. Pathak, PMP, PfMP 

Judy Payne, PhD, MBA 

Nagy Attalla Saad, PMP, ITIL 

Davidov Shai 

Kavita Sharma, PMP, RMP 
Jurgen T. Sturany, PMP 
DirkWithake, PgMP, PMP 
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X2.3 COMITE CONTENU DE LA SIXIEME EDITION DU PMBOK® GUIDE 


Les personnes ci-dessous ont participe aux textes ou aux concepts et formule des recommandations relatives aux 
projets de la Sixieme edition du Guide PMBOK ®: 

Vahid Azadmanesh, MBA, PMP 
Brad Bigelow, PMP, MSP 
Wayne R. Brantley, MSEd, PMP 
MarceloA. Briola PhD, PMP 
Michael C. Broadway, PMP 
Mariana Nella Caffarena Bolivar 
Steven Flannes 

Sandra Fonseca, PhD, CISA, CRISC 

Theofanis C. Giotis, PMP, PMI-ACP 

Piyush Govil, BE, PMP 

Rex M. Holmlin, PE, PMP 

EamonnV. Kelly, DBA, PMP 

Srikanth Krishnamoorthy 

Fabiano de Alcantara de Lima, PhD, PMP 

Shashank Neppalli 

Andrea Pantano 

Kristine Persun, PMP 

Piyush Prakash PMP, Prince 2 

Raju N. Rao, PMP, SCPM 

Krupakar Reddy, PMP, PRINCE2 Practitioner 

Emadeldin Seddik, PhD, PMP 

Tejas V. Sura, PMP, PfMP 

Nicholas Tovar 

Fede Varchavsky, MBA, PMP 

Angelo Valle, PhD, CRK 

Ronald H. Verheijden, PMP 
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X2.4 REVISEURS 


X2.4.1 REVUE SME 

Outre les membres du comite, les personnes suivantes ontfait part de leurs commentaires et leurs recommandations 
sur les projets du standard : 

David P. Bieg, PMI-PBA 

James F. Carilli, PMP, PgMP 

Shika Carter, PMP, PgMP 

Dan Deakin, PMP, CISSP 

Theofanis C. Giotis, PMP, PMI-ACP 

Dave Gunner, MSc, PMP 

George Jucan, PMP 

Ginger Levin, PhD, PMP, PgMP 

Vanina Mangano, PMP, PMI-RMP 

Juan Carlos Moreno, MBA, PMP 

Marvin R. Nelson, MBA, SCPM 

Klaus Nielsen, MBA, PMP 

Chris Richards, PMP 

Ivan Rincon, MBA, PMP 

Shaligram Pokharel, REng (Nepal), PhD 

Paul E. Shaltry, MA, PMP 

Carolina Gabriela Spindola, PMP, SSBB 

Langeswaran Supramaniam, C Build E FCABE, PMP 

Michael A Yinger 
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X2.4.2 REVUE DE L’EXPOSE SONDAGE FINAL (PARTIE STANDARD) 


Outre les membres du comite, les personnes suivantes ontformule des recommandations en vue d’ameliorer I’expose 
sondage de la Sixieme edition du Guide PMBOK® (partie standard): 


Ahmed A. Raouf Hamdy, PhD, PMP 
Farhad Abdollahyan, PMP, OPM3 CP 
Adil Abdulghani 
Tetsuhide Abe, PMP 
Klaus Abert 

Ayodeji R.Abitogun, MBA, PMP 
Taiwo Abraham 
Mohammad I. Abu Irshaid, 

PMP, PfMP 
Manuel Acosta A. 

Phill C.Akinwale, MSc, PMP 
Mazen Al Bazreh 
Jose Rafael Alcala Gomez, PMP 
Ameer AN 

Hammam Zayed Alkouz, 

PMP, PMI-RMP 
Bill Allbee, PMP 
CharmaineY. Allen, PMP, PBA 
Kristin L. Allen, PE, PMP 
Abdulaziz Almalki 
Ayman Alminawi, MBA, PMP 
Ahmad Moh. Al-Musallami, 

MSc, PMP 

Imad Alsadeq, P3M3, MB 
Mohammed Ahmad S.AI-Shamsi, 
PhD, PEng 

Essam Alsultan, MBA, PMP 
Haluk Altunel, PhD, PMP 
PriscillaS. R. Alves, PMP 
Angelo Amaral 
Barnabas Seth Amarteifio, 

PMP, ITIL (expert) 

Wilson Anandaraj, MBA, PMP 
Guillermo Anton 
John Aogon, PMP 
Hamid Aougab, PMP, PMI-ACP 


Charalampos Apostolopoulos, 

PhD, PMP 
Rodolfo Arguello 
Abd Razak B Ariffin, PMP 
DeepakArora, MBA, PMP 
C. H. ArunPrabu, PMP 
Zaher Asfari, MBA, PMI-ACP 
Ayman Atallah, BE, PMP 
Reza Atashfaraz, MSc, PMP 
SharafA.Attas, PMP, PMI-RMP 
Abdurazaq Attuwaijri 
Ashraf M Awwad, MSc, PMP 
Vikram Kumar B. T. 

Nabeel Eltyeb Babiker, PMP, P30 
Mohamed A Badie, PMP, 

Prince2 Practitioner 
Smitha Balakrishnan 
Saket Bansal, PMP, PMI-ACP 
Manuel F. BaqueroV., MSc, PMP 
Haytham Baraka, PMP, CCP 
Robert Barclay 
Karuna Basu 

Joy Beatty, PMI-PBA, CBAP 
Frances Bellows, PMP, ACP 
Peter G. Bembir, MPhil, PMP 
Anis Ben Hassen, Msc Project/ 
Programme/Portfolio 
Management, PMP 
Racquel Benedict 
German Bernate, MPM 
Bryan D. Berthot, MBA, PMP 
Karl F. Best, PMP, CStd 
Shantanu Bhamare, PMP, UMC 
Jasbir Singh Bhogal, PMP, ITIL-V3 
Michael M. Bissonette, MBA, PfMP 
Molly Blake-Michaels, MS, PMP 


Nigel Blampied, PE, PMP 

Wolfgang Blickle, PMP, PMI-ACP 

Jaqueline Boeck 

Dennis L. Bolles, PMP 

Kiron D. Bondale, PMP, PMI-RMP 

Raul Borges, PMP 

Farid F. Bouges, PhD, PMP, PfMP 

Joao Boyadjian 

Damiano Bragantini, PMP 

Ralf Braune 

Kevin Brennan 

Naga Pradeep Buddhavarapu, PMP 
David E. Buehler, PMP 
Susan M. Burk 
Andrea Caccamese, PMP, 

Prince2 Practitioner 
Roberto A. Cadena Legaspi, 

PMP, MCI 

Shawna D. Camp, MBA, PMP 
Iker Castillo, PMP 
Igor Castro 

Helena Cedersjo, MSc, PMP 
Balasubramanian Chandrasekaran, 
BE, PMP 

Joo-Kwan Chang 

Panos Chatzipanos, PhD, Dr Eur Ing 
Pengzhi Chen, PMP, MSC 
Wilson Lee Chung, PMP 
Xavier Clerfeuille, 

MSc, SSL Black Belt 
Martin A. Collado, PMP, ITIL 
Sergio Luis Conte, PhD, PMP 
Lawrence (Larry) Cooper, 

PMP, PMI-ACP 
Helio R. Costa, DSc 
Scott Cunningham 
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Adriano Jose da Silva Neves 
Hernan D’Adamo, MPM, PMP 
Michelle Daigle, PMP 
Larry C Dalton, PfMP, PgMP 
Farshid Damirchilo, MSc 
Tran Dang 

Teodor Darabaneanu, PMP, MEng 
Russell W. Darnall, DM, PMP 
Edson G. Freitas, PMP 
Jean-Michel de Jaeger, EMBA, PMP 
Maria Angela de Souza Fernandes 
Allan E. Dean PMP, PgMP 
G. Murat Dengiz, PMP 
Valerie P. Denney, DBA, PMP 
Jacqueline E. Dennis, PMP, PgMP 
Konika Dey, MCA, PMP 
Cyndi Snyder Dionisio, MBA, PMP 
Ajay Kumar Dixit, MBA, B Tech 
Roland Doerr, MSc, PMP 
Rex Wotan Dominguez Chang 
Jorge Duenas-Lozano 
Stephen M. Duffield, MPM, CPPD 
Josee Dufour, PMP 
Darya Duma, PEng, PMP 
Keiran J. Dunne, PhD 
Awab Elameer, PMP, PMI-SP 
Khaled EL-Nakib, MSc, PMP 
Yasir Elsadig, PMP, PfMP 
Majdi N. Elyyan, PMP, PMI-RMP 
Pedro Engracia 
MarkW. Erwin, PMP, PMI-ACP 
Behnam Faizabadi, PhD, PMP 
Marco Falcao, PMP, PMI-RMP 
Puian Masudi Far, PhDc, PMP 
Jamil Faraj 

Saurater Faraday, PMI-RMP 
Fereydoun Fardad, PMP, PRINCE2 
Sergio Ferreto Gutierrez, 

MPM, MBA 
David Foley, MBA 


Les Foley, MPM, PMP 
Gloria Folle Estrada, PMP 
Frank P. Forte, PMP 
Laura Franch, PMP 
Nestor C. Gabarda Jr., ECE, PMP 
Jaime Garcia Castro, PMP 
Sam Ghavanloo, PMP 
Ing Gustavo Giannattasio 
MBA, PMP 
Sheila Gibbs 

Carl M. Gilbert, PMP PfMP 
Theofanis Giotis, PhDc, PMP 
JoseAbranches Gongalves, 

MSc, PMP 

Juan Carlos Gonzalez, 

PMP, PMI-ACP 
Jean Gouix, PMP, PgMP 
Therese Graff 

Scott M. Graffius, PMP, CSM 
Brian Grafsgaard, PMP, PgMP 
Sara Grilli Colombo 
Anita Griner 

Maxim Grishin, PhD, PMP 

Robert C Grove, MBA, PMP 

David Guan, PMP 

Juan E. Guarache, V, BEng, PMP 

Pier Luigi Guida 

Vijay Guliani, PMP, PMI-PBA 

Tomasz Gutmanski 

Omar Haddad, CAPM, PMP 

Mustafa Hafizoglu, PMP 

Yoshifumi Hamamichi 

Simon Harris, PMP, CGEIT 

Patti M. Harter, PMP 

Sean Shraden Hasley, MSIT-PM 

Ahmed Hassan 

Akram Hassan, PhD, PMP 

Susumu Hayakawa, PMP 

Bruce A. Hayes, PMP 

Guangcheng He, PMP 


David G. Hendrickson, PMP 
Barbara Henrich 
Baruch Herrera 
Sergio Herrera-Apestigue, 

PMP, P30 

Robert Hierholtz, PhD, MBA, PMP 
Robert N. Higgins V, 

PMP, ITIL Expert 

David A. Hillson, PhD, PMI Fellow, 
HonFAPM 

Shirley Hinton, PMP 
Kenji Hiraishi, MsE, PMP 
Lenora Holmsten, PMP, MPM 
Jenny Anne Horst-Martz, JD, PMP 
Alfred J. Howard, PMP, ITIL Expert 
Cynthia L. Hoxey, PMP 
Gheorghe Hriscu, PMP, CGEIT 
Ananth HV PMP, CSM 
Guillermo A. Ibanez, PMP, ITIL 
Victor Manuel Ibanez Salazar, 

PMP, MA 
Waleed Idris 
Shuichi Ikeda, PMP 
Andrea Innocenti PMP, CGEIT 
Can Izgi, PMP 
Pablo Jaramillo 
Tariq Javed, MS, PMP 
Cari Jewell, PMP, MISST 
Gabriela Jimenez P. 

Icvillajoe Joe 

Tony Johnson, PMP, PfMP 
Michele J. Jones, PMP 
Yves Jordan, PMP 
Alisher Kabildjanov, PMP 
SS Kanagaraj, PMP, ITIL 
Naoki Kasahara, PMP 
Arcady Katnikov 
Suhail Khaled 
Basher Khalil 

Aaron Ho Khong, PMP, ITIL Expert 
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M. Raashid Kiani, PMP, CSM 
Taeyoung Kim, PMP 
Ariel S. Kirshbom, PMP,ACP 
Konstantinos Kirytopoulos, 

PhD, PMP 
Ian Koenig PMP 
Athens Kolias, MPM, PMP 
Henry Kondo, PMP, PfMP 
Maciej Koszykowski, 

PMP, PMI-RMP 
Rouzbeh Kotobzadeh, 

PMP, PMI-ACP 
Srikanth Krishnamoorthy, 

PMP, PGDSA 
Am it Kumar 
Devesh Kumar 
Pramit Kumar, PMP 
Rakesh Kumar, MBA, PMP 
Santosh Kumar 
S. Y. Satish Kumar 
Abhilash Kuzhikat, PMP, CISA 
Thierry Labriet 

G.Lakshmi Sekhar, PMP, PMI-SP 

Boon Soon Lam 

Vincent Hiu Sing Lam, PMP 

Ruchie Lamba 

Deborah Langlois MBA, PMP 

Alvaro Latorre,MsC, PMP 

Olivier Lazar 

Chang-Hee Lee, PMP, CISA 
Cheryl G. Lee, PMP, PMI-PBA 
Oliver F. Lehmann, MSc, PMP 
Michael J Leisegang, PMP 
Craig Letavec, PgMP, PfMP 
Jean-Pierre Lhomme, PMP 
Junquan Liu 
Shihan Liu 

Tong Liu (James Liu), PhD, PMP 
Anand Loganathan, MS 
Anand Lokhande, PMP 


Nancy Lopez 

Samuel Lopez Gonzalez de Murillo, 
MPM,PMP 

Carlos Lopez Javier, MBA, PMP 
Zheng Lou, MBA, PMP 
Sergio Lourengo, PMP, PMI-RMP 
Catia Lourengo 

Hugo Kleber Magalhaes Lourengo, 
PMP, ACP 

Amy S. Lugibihl, PMP 
Sergio 0. Lugo, MBA, PMP 
Vijaya Prasanth M. L., PMP, MCTS 
Jose Carlos Machicao, MSc, PMP 
Frederick G. Mackaden, 

CRISC, PMP 
Jas Madhur 

Krishan Gopal Maheshwari, 

PMP, ITILv3 Expert 
Konstantinos Maliakas, 

MSc (PM), PMP 
Rich Maltzman, PMP 
Vaios Maniotis 

Antonio Marino, PMP, PMI-ACP 
Gaitan Marius Titi, Eng, PMP 
Photoula Markou-Voskou 
Lou Marks, PMP 

Cristian Martin Corrales, MPM, PMP 
Mike McElroy, MHA, PMP 
Jon McGlothian, MBA, PMP 
William T. McNamara, PMP 
Rob D. Meadows, MBA, PMP 
Alain Patrick Medenou, 

PMP, PRINCE2 Practitioner 
Lourdes Medina, PMP, PfMP 
Peter Berndt de Souza Mello, 
PMI-SP, PMP 
Yan Bello Mendez 
Ernst Menet, PMP 
Sunil Meshram, PMP 
Mohammed M’Hamdi, PMP 


Lubomira Mihailova, MBA, PMP 
Gloria J. Miller, PMP 
Romeo Mitchell, MSc, BSc 
Mannan Mohammed, Peng, PMP 
Venkatram Vasi Mohanvasi 
Ricardo Monteiro 
Paula Morais 
Maciej Mordaka, PMP 
Rachel A. Morris, PMP 
Doris Moss 

Henrique Moura, PMP, PMI-RMP 
Timur Mukharyamov, PhD, PMP 
Antonio Muntaner, PMP 
Muktesh Murthy, MBA (IS), PMP 
Lemya Musa M. Idris, 

PMP, PMI-PBA 

Khalid M. Musleh, PMP, PMI-RMP 
SyedAhsan Mustaqeem, PE, PMP 
Todd Nielsen Myers, MBA, PMP 
Narayanaswamy Nagarajan, PMP 
Kiran Nalam 
Faig Nasibov, PMP 
Asad Naveed, PMP, RMP 
Serge Patrick N'Guessan, 

MSIS, PMP 
Praveen K. Nidumolu, 

PMP, PMI-ACP 
Eric Nielsen, PMP 
Jeffrey S. Nielsen, PMP, PgMP 
Victor Nieva Martin-Portugues, PMP 
Michael C. Nollet, PMP, PMI-ACP 
Takamasa Nomura 
Ernesto Antonio Noya Carbajal 
Mufaro M. Nyachoto, 

PMI-PBA, CAPM 
Conor O’Brien, 

MBA (Tech Open), PMP 
Peter 0’Driscoll 

Michael 0. Ogberuhor, PMP, EVP 
Bayonle Oladoja, PMP, PRINCE2 
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Antonio Oliva Gonzalez, PMP, EMPM 
Habeeb Omar, PgMP, PfMP 
Stefan Ondek, PMP 
Marian Oprea, PMP, ITIL 
Henrique Ortega-Tenorio, PMP 
Venkateswar Oruganti, FIETE, PMP 
Musab Abdalmageed Osman 
Abubakar 

Jaime Andres Alvarez Ospina, 

PMP, PMI-RMP 
TabithaA. Palmer, PMP 
Neeraj Pandit, PMP 
Luke Panezich, PMP, PMI-ACP 
Hariyo Pangarso 
Laura Paton, PMP, PMI-PBA 
Seenivasan Pavanasam, 

PMP, PgMP 
Anil Peer, PEng, PMP 
Mauricio Perez Calvo, 

PMP, PMI-RMP 

Dana Persada Mulyoto, MBA, PMP 

LEE Nan Phin, PMP, CSM 

Luca Pietrandrea 

Crispin (“Kik”) Piney, BSc, PgMP 

Jose Angelo Pinto, PMP, OPM3 CP 

Narendra Pondugula, PMP, PMI-ACP 

Hin-Fei Poon 

Svetlana Prahova, PMP 

B. K. Subramanya Prasad, PMP, CSM 

T.V. Prasanna Raaj, PMP 

Suhail Qadir, PMP, BTech 

Collin Quiring, PMP, OPM3 

Nader K. Rad, PMP 

Noalur Rahim, PMP 

Prashanth Bagepalli Rajarao, 

BE, PMP 

S. Ramani, PgMP, PfMP 
Gurdev S. Randhawa, PMP 
Alakananda Rao 
Vicky Restrepo, PMP 


Raman Rezaei 
Tashfeen Riaz, PMP, MPM 
Juan Carlos Rincon Acuna, 

PhD, PMP 

Juan Sebastian Rivera Ortiz 
Dan Roman, PMP, PMI-ACP 
Rafael Fernando Ronces Rosas, 
PMP, ITIL 

David W. Ross, PMP, PgMP 
Kaydashov Ruslan, PMP 
Philip Leslie Russell, PMP 
Mohamed Salah Eldien Saad, PMP 
Eyad Saadeh, PfMP, PgMP 
Imad Sabonji, PMP 
Kumar Sadasivan, PMP 
Mihail Sadeanu, PhD, PMP 
Gopal Sahai, PMP, PMI-PBA 
Joudi Ahmad Said, PMP, MSc 
Ibrahim Saig, PhD, PMP, MRCPI 
Brian Salk, PhD, PMP 
Omar A. Samaniego, PMP, PMI-RMP 
Abubaker Sami, PfMP, PgMP 
Carlos Sanchez Golding, PMP 
Yiannis Sandis, MSc, PMP 
Ivan S.Tejera Santana, 

PMP, PMI-ACP 

Murali Santhanam, PMP, BCom 
Subhendu Sarangi 
Saikat Sarkar, PMP 
Shreesh Sarvagya 
Supriya Saxena 
Nicole Schelter, PMP 
Kathy Schwalbe, PhD, PMP 
Dion Serben 

Marcus Gregorio Serrano, 

MBA, PMP 

Isaac Sethian, MBA, PMP 
Bruce G. Shapiro, PMP 
Ian Sharpe, 4-DM CPPD 
Cindy C Shelton, PMP, PMI-ACP 


Nitin Shende, PMP, PRINCE2 
Gregory P. Shetler, PhD, PgMP 
Patricia C. C. Sibinelli, MEng, PMP 
Alexsandro Silva 
Christopher M. Simonek, PMP 
Rohit Singh 

Sathya Sivagurunathan 
Venkatramanan S., PMP 
Michelle A. Sobers, MS 
Pamela L. Soderholm, PMP 
Khaled Soliman 
Mauro Sotille, PMP, PMI-RMP 
Sriram Srinivasan, PMP, CGEIT 
Pranay Srivastava, PMP, CSM 
Alexander Stamenov 
Jamie Stasch 

John Stenbeck, PMP, PMI-ACP 
Michael J. Stratton, PhD, PMP 
S. Sudha, PMP 
John L. Sullivan, MEd, PMP 
Karen Z. Sullivan, PMP, PSM 
Surichaqui Yasuji Suzuki, PMP 
Mark A. Swiderski, PMP, MBA 
Titus K. Syengo, PMP 
Paul S. Szwed, DSc, PMP 
Hadi Tahmasbi Ashtiani 
Shoji Tajima, PMP, ITC 
Peter Tashkoff, PMP 
Ahmet Taspinar 
Gokrem Tekir 
Sunil Telkar PMP, PGDBL 
Sal J. Thompson, MBA, PMP 
Mark S. Tolbert, PMP, PMI-ACP 
Mukund Toro, PMP 
Stephen Tower, PMP, MBCI 
John Tracy, PMP, MBA 
Biagio Tramontana, Eng, PMP 
Micol Trezza, MBA, PMP 
Konstantin Trunin, PMP 
AhmetTumay, PhD, PMP 
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M. Jeffery Tyler, PMP 
Hafiz Umar, MBA, PMP 
KrishnakantT. Upadhyaya, PMP 
Atta Ur Rahman, MBA, PMP 
Ebenezer Uy 
Madhavan V. 

Ali Vahedi Diz, PgMP.PfMP 
Tom Van Medegael, PMP 
Stephen VanArsdale 
Enid T. Vargas Maldonado, 

PMP, PMI-PBA 
Paola D. Vargas 
Allam V. V. S.Venu, PMP, PgMP 
Roberto Villa, PMP 
Tiziano Villa, PMP, PMI-ACP 
Benjamin Villar Lurquin, Bs 
Dave Violette, MPM, PMP 
Vijay Srinivas Vittalam PMP, RMP 
Julian Vivas 

Sameh Wahba, PMP, CPMC 
Prakash Waknis, PMP 
Xiaojin Wang, PhD, PMP 
Tsunefumi Watanabe, PMP 
Barbara A. Waters, MBA, PMP 
Shayla P. Watson, MA 
Patrick Weaver, PMP, PMI-SP 
Kevin R. Wegryn, PMP, Security+ 
Lars Wendestam, MSc, PMP 
Jan Werewka, PMP 
Carol E. P. Whitaker, MBA, PMP 
Sean Whitaker, MBA, PMP 
Angela Wick, PMP, PBA 
Michal P. Wieteska 
J. Craig Williams 
Malgorzata Wolny 
Sek-Kay Steve Wong, MBA, PMP 
Louise M. Worsley 
Yan Wu,APME, PMP 
ClementC. L. Yeung, PMP 


Cynthia J. Young, 

PhD, PMP, LSSMBB 
Gordon Young 
Alan E.Yue, PMP, PMI-ACP 
Hany I. Zahran 
Saeed Zamani 

Alessandri Zapata Rosas, PMP 
Azam M. Zaqzouq, MCT, PMP 
Salim Zid, MSc, PMP 
Eire Emilio Zimmermann 
Marcin Zmigrodzki, PhD, PgMP 
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X2.4.3 REVUE DE L’EXPOSE SONDAGE FINAL (PARTIE GUIDE) 


Outre les membres du comite, les personnes suivantes ontformule des recommandations en vue d’ameliorer I’expose 
sondage de la Sixieme edition du Guide PMBOK® (partie guide): 


Farhad Abdollahyan, PMP, OPM3CP 

Tetsuhide Abe, PMP 

Ali Abedi, PhD, PMP 

Amir Mansour Abdollahi, MSc, PE 

Eric Aboagye 

Umesh AC 

JerAdamsson 

Carles Adell, MPM, PMP 

MounirA. Ajam, RMP, GPM-bTM 

Ugur Aksoylu, PMP 

TarikAI Hraki, PMP, PMI-RMP 

Melad Al Aqra, PMP, MIET 

Amer Albuttma, BSc, PMP 

Jose Rafael Alcala Gomez, PMP 

Filippo Alessandro, PMP 

Hammam Zayed Alkouz, 

PMP, PMI-RMP 
Eric Allen 

Wasel A. Al-Muhammad, MBA, PMP 
Turki Mohammed Alqawsi, MITM 
Imad Alsadeq, MB, P3M3 
Haluk Altunel, PhD, PMP 
Barnabas Seth Amarteifio, 

PMP, ITIL (expert) 

Serge Amon, MBA, PMP 
Abd Razak B Ariffin, PMP 
Sridhar Arjula 

Kalpesh Ashar, PMP, PMI-ACP 
Vijaya C. Avula, PMP, ACP 
Andy Bacon, PMP, CSP 
Andrey Badin 
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ANNEXE X3 

ENVIRONNEMENTS DE PROJET AGUES, ITERATIFS, 
ADAPTATIFS ET HYBRIDES 


Cette annexe etudie les nuances selon lesquelles les groupes de processus de management de projet, decrits dans le 
standard de management de projet «The Standard for Project Management», sont executes eu egard a I'environnement 
et au cycle de vie du projet. 

La section 1.4.2.1 du Guide PMBOK® indique que «le cycle de vie du projet doit etre suffisamment flexible pour 
traiter les divers facteurs du projet». II est dans la nature des projets d’evoluer au fur et a mesure que des informations 
plus detaillees et specifiques sont disponibles. Cette capacite devolution et d’adaptation est plus pertinente dans les 
environnements a haut degre de changement et d’incertitude ou dans lesquels I’interpretation et les attentes des parties 
prenantes sont tres diverses. 


X3.1 LE CONTINUUM DES CYCLES DE VIE DU PROJET 

Pour comprendre I’application du processus dans les projets adaptatifs, il convient de definir le continuum des cycles 
de vie du projet. Le glossaire du Guide PMBOK decrit le cycle de vie d’un projet comme etant«la serie de phases que 
celui-ci traverse, depuis son demarrage jusqu’a sa fin». Au sein du cycle de vie du projet, on trouve generalement une ou 
plusieurs phases qui sont associees au developpement du produit, du service ou du resultat. Ces phases composent le 
cycle de vie du developpement, qui peut etre predictif (fonde sur un plan), adaptatif (agile), iteratif, incremental ou hybride. 

La figure X3.1 presente les differentes fagons de traiter les exigences et les plans, la gestion des risques et des couts, 
les considerations liees a I’echeancier et la gestion de I’implication des principales parties prenantes en fonction du type 
de cycle de vie utilise. 
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Cycle predictif 

Cycle Iteratif Cycle incrementiel 

Cycle agile 
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Les exigences sont definies au depart 
avant le debut du developpement. 

Les exigences peuvent etre definies 
a intervalles reguliers au cours 
de la livraison. 

Les exigences sont definies 
frequemment en cours de livraison. 

Des plans sont proposes pour 
le livrable eventuel. Ensuite, seul 
un produit final est livre a I’echeance 
du projet. 

La livraison peut etre divisee 
en sous-ensembles du produit total. 

La livraison a lieu frequemment avec 
des sous-ensembles du produit 
global interessants pour le client. 

Le changement est limite autant 
que possible. 

Tout changement est integre 
a intervalles periodiques. 

Tout changement est integre en 
temps reel lors de la livraison. 

Les principales parties prenantes 
interviennent a des jalons specifiques. 

Les principales parties prenantes 
interviennent regulierement. 

Les principales parties prenantes 
interviennent constamment. 

Les risques et les couts sont 
maftrises a I'aide de la planification 
detaillee de considerations 
susceptibles d’etre connues. 

Les risques et les couts sont 
maftrises grace a I’elaboration 
progressive des plans sur la base 
des nouvelles informations. 

Les risques et les couts sont 
maftrises au fur et a mesure que 
les exigences et les contraintes 
apparaissent. 


Figure X3-1. Le continuum des cycles de vie du projet 


Les cycles de vie d’un projet predictif se caracterisent par I’attention qu’ils portent a la specification des exigences 
et une planification detaillee au cours des premieres phases du projet. Des plans detailles fondes sur les exigences et 
les contraintes connues peuvent reduire les risques et les couts. Des jalons pour la participation des principals parties 
prenantes sont egalement prevus. A mesure que le plan detaille est execute, les processus de martrise visent a limiter les 
changements susceptibles d’influer sur le perimetre, I’echeancier ou le budget. 

Les cycles de vie tres adaptatifs ou agiles se caracterisent par (’elaboration progressive des exigences sur la base de 
petits cycles de planification et d’execution iteratifs. Les risques et les couts sont reduits grace a revolution progressive 
des plans initiaux. Les principales parties prenantes sont impliquees en permanence et donnent des retours d’information 
frequents, ce qui permet de reagir aux changements plus rapidement et de garantir une meilleure qualite. 

Les considerations suivantes s’appliquent au centre du continuum du cycle de vie: les risques et les couts sont reduits 
grace a revolution iterative des plans initiaux; les principales parties prenantes ont plus d’opportunites de participer aux 
cycles incrementaux, iteratifs et agiles que lors des jalons du projet dans les cycles de vie tres predictifs. 

Les cycles de vie du projet situes au centre du continuum du cycle de vie ont tendance a mieux refleter le cote predictif 
ou le cote agile selon la fagon dont les exigences sont specifies, la gestion des risques et des couts mais aussi la nature de 
la participation des principales parties prenantes. Les projets dans cette partie du continuum peuvent utiliser des methodes 
de projet hybrides. 

II convient de souligner que les cycles de vie du developpement sont complexes et multidimensionnels. Souvent, 
les multiples phases d’un projet donne utilisent differents cycles de vie, tout comme des projets distincts au sein d’un 
programme particulier peuvent etre executes differemment. 


666 


Troisieme partie - Annexe X3 












X3.2 PHASES DE PROJET 


La section 1.2.4.2 du Guide PMBOK® definit les phases comme«un ensemble d’activites du projet liees logiquement 
qui aboutit a I’achevement d’un ou de plusieurs livrables». Dans chacun des groupes de processus, les processus sont 
repetes si besoin dans chaque phase jusqu'a ce que le critere d'achevement de cette phase soit satisfait. 

Les projets du cote le plus adaptatif du continuum utilisent deux modeles recurrents pour les relations entre les 
phases du projet, comme decrit aux sections X3.2.1 et X3.2.2. 


X3.2.1 PHASES SEQUENTIELLES FONDEES SUR DES ITERATIONS 

ALes projets adaptatifs se decomposed souvent en une sequence de phases appelees iterations. Chaque iteration 
utilise les processus de management de projet pertinents. Ces iterations creent un rythme, avec une duree coherente 
previsible, divisee en blocs de temps predefinis (timebox), qui contribue a la planification. 

L’execution repetee des groupes de processus implique des surcouts. Ils sont considers comme necessaires pour 
la gestion efficace des projets a haut degre de complexity, d'incertitude et de changement. Le niveau d'effort pour les 
phases fondees sur des iterations est illustre a la figure X3-2. 



Figure X3-2. Niveau d’effort pour les groupes de processus au cours des cycles d’iteration 
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X3.2.2 PHASES CONTINUES DE CHEVAUCHEMENT 


Les projets tres adaptatifs executent souvent tous les groupes de processus de management de projet en continu tout 
au long du cycle de vie du projet. Inspiree des techniques de la pensee« Lean», cette approche est souvent consideree 
comme une « planification continue et adaptative », reconnaissant que, des le debut du travail, le plan change et 
que le plan doit refleter cette nouvelle connaissance. L'objectif vise a affiner et ameliorer tous les elements du plan 
de management du projet de maniere dynamique, au-dela des points de controle predefinis associes aux iterations. 
L’interaction des groupes de processus dans cette approche est illustree a la figure X3-3. 



r 


Figure X3-3. Relation des groupes de processus dans les phases continues 


Ces approches tres adaptatives extraient en permanence des taches a partir d’une liste de travail organisee par ordre 
de priorite. La suppression du debut et de la fin des activites de I’iteration permet de minimiser les surcouts dus a la 
gestion repetitive des groupes de processus. Les systemes d’extraction en continu peuvent etre considers comme des 
micro-iterations axees sur I’optimisation du temps consacre a I’execution plutot qu’a la gestion. Cependant, ils ont besoin 
de leurs mecanismes de planification, de suivi et d’ajustement afin de garder le cap et de s’adapter aux changements. 
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X3.3 GROUPES DE PROCESSUS DANS LES ENVIRONNEMENTS ADAPTATIFS 


Comme indique dans la section precedente, chaque groupe de processus de management de projet est execute dans 
les projets sur I’ensemble du continuum des cycles de vie d’un projet. Selon que le cycle de vie est adaptatif ou tres 
adaptatif, I’interaction entre les groupes de processus varie. 


X3.3.1 GROUPE DE PROCESSUS D’INITIALISATION 

Ces processus permettent de definir un nouveau projet, ou une nouvelle phase d’un projet existant, par I’obtention 
de I’autorisation de demarrer ce nouveau projet ou cette nouvelle phase. Les projets adaptatifs revoient et revalident 
frequemment la charte du projet. A mesure que le projet avance, les contraintes et les criteres de succes du projet 
peuvent devenir obsoletes en raison des priorites concurrentes et des changements de dynamique. Pour cette raison, 
dans les projets adaptatifs, les processus d’initialisation sont regulierement executes afin de garantir revolution du 
projet dans la limite des contraintes et vers les objectifs qui refletent les dernieres informations. 

Les projets adaptatifs s'appuient essentiellement sur un client averti ou un representant designe par le client qui peut 
formuler des besoins et des souhaits et donner un retour d’information sur le nouveau livrable de maniere continue 
et permanente. L’identification de cette partie prenante ou d’autres parties prenantes au debut du projet permet des 
interactions frequentes au cours des processus d’execution et de martrise. Le retour d’information associe permet de 
garantir la livraison des bonnes donnees de sortie du projet. Comme indique precedemment, un processus d'initialisation 
est generalement execute lors de chaque cycle iteratif d’un projet fonde sur un cycle de vie adaptatif. 


X3.3.2 GROUPE DE PROCESSUS DE PLANIFICATION 

Ces processus permettent de definir le perimetre du projet, d’affiner les objectifs et de decider des actions necessaires 
a I’atteinte des objectifs pour lesquels le projet a ete entrepris. 

Les cycles de vie du projet tres predictifs se caracterisent generalement par les rares changements apportes au 
perimetre du projet et un fort alignement des parties prenantes. Ces projets beneficient d’une planification detaillee en 
amont. Les cycles de vie adaptatifs, en revanche, permettent d’elaborer un ensemble de plans globaux pour les exigences 
initiales et de definir progressivement des exigences a un niveau de detail approprie pour le cycle de planification. Par 
consequent, les cycles de vie adaptatif et predictif different en ce qui concerne le degre et le moment de la planification. 

En outre, les projets presentant de hauts degres de complexity et d'incertitude doivent faire intervenir un maximum 
de membres de I’equipe projet et de parties prenantes dans les processus de planification. L'objectif vise a surmonter 
I’incertitude en integrant un vaste groupe de donnees d’entree dans la planification. 
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X3.3.3 GROUPE DE PROCESSUS D’EXECUTION 


Ces processus permettent d’accomplir le travail defini dans le plan de management du projet afin de satisfaire aux 
exigences du projet. 

Dans les cycles de vie agiles, iteratifs et adaptatifs, le travail est dirige et gere a I’aide d’iterations. Chaque iteration 
est un laps de temps court et fixe pendant lequel un travail est entrepris, suivi d’une demonstration de la fonctionnalite 
ou de la conception. Sur la base de la demonstration, les parties prenantes concernees et I’equipe menent une revue 
retrospective. La demonstration et la revue permettent de verifier I’avancement par rapport au plan et de determiner 
la necessity de changer le perimetre du projet, I'echeancier ou les processus d’execution. Ces sessions permettent 
egalement de gerer I’engagement des parties prenantes en montrant les increments du travail effectue et en examinant 
le travail futur. La retrospective permet egalement d'identifier les problemes lies a I'approche d’execution et de les 
examiner, avec les idees d’amelioration, dans un delai opportun. Les retrospectives constituent un outil essentiel pour 
gerer les connaissances du projet et developper I’equipe, car elles permettent d'aborder ce qui fonctionne bien et de 
resoudre les problemes en equipe. 

Si le travail est entrepris via de courtes iterations, il est egalement suivi et gere selon des delais de livraison a plus 
long terme. Les tendances liees a la vitesse de developpement, aux depenses, aux taux de defauts et a la capacite 
de I’equipe, suivies au niveau d’une iteration, sont additionnees et extrapolees au niveau du projet afin de suivre les 
performances d’execution. Les approches tres adaptatives visenta utiliser les connaissances specialises d’une equipe 
pour I'achevement d’une tache. Au lieu de selectionner et de sequencer le travail, le chef de projet explique les objectifs 
globaux. Les membres de I’equipe sont ainsi habilites a organiser eux-memes des taches specifiques afin de mieux 
repondre a ces objectifs. Cela permet de creer des plans pratiques et des hauts niveaux d’adhesion de la part des 
membres de [’equipe. 

Les equipes juniors qui travaillent sur des projets tres adaptatifs necessitent generalement d’etre encadrees et de 
se voir attribuer des taches avant d’atteindre ce niveau d’autonomie. Cependant, apres des essais progressifs dans les 
limites d’une iteration courte, les equipes sont passees en revue dans le cadre de la retrospective afin de determiner si 
elles ont acquis les competences requises pour travailler seules. 
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X3.3.4 GROUPE DE PROCESSUS DE MAITRISE 


Le groupe de processus de martrise inclut les processus permettant de suivre, de passer en revue et de reguler 
I’avancement et la performance du projet, d’identifier les endroits ou des changements du plan s'averent necessaires 
et d’apporter les changements correspondants. 

Les approches iteratives, agiles et adaptatives suivent, passent en revue et regulent I'avancement et la performance 
en tenant a jour un backlog. Ce backlog est organise par ordre de priorite par un representant de I'organisation avec 
I'aide de I'equipe projet, qui estime les dependances techniques et fournit des informations a ce sujet. Le travail est 
extrait du haut du backlog pour la prochaine iteration en fonction de la priorite de I'organisation et de la capacite de 
I’equipe. Les demandes de changement et les rapports d’erreur sont evalues par le representant de I'organisation en 
consultation avec I’equipe en ce qui concerne les donnees d’entree techniques, puis classes par ordre de priorite dans 
le backlog de travail. 

Cette approche fondee sur une seule liste de travail et de changements est nee dans des environnements de projet ou 
les taux de changement tres eleves avaient tendance a saper toute tentative de separer les demandes de changement 
du travail initialement planifie. Reunir ces flux de travail dans un seul backlog facilement resequengable offre un seul et 
meme endroit ou les parties prenantes peuvent gerer et maitriser le travail du projet, effectuer le suivi des changements 
et valider le perimetre. 

Au fur et a mesure que les taches prioritaires et les changements sont extraits du backlog et executes via des 
iterations, que des tendances et des metriques liees au travail accompli sont etablies, on calcule I’effort de changement 
et les taux de defauts. En echantillonnantfrequemment les progres via de courtes iterations, des mesures de la capacite 
de I’equipe et de I’avancement par rapport au perimetre original sont effectuees en mesurant le nombre des impacts 
lies aux changements et le nombre des efforts de correction des defauts. Ces mesures permettent d’estimer le cout, 
I'echeancier et le perimetre a etablir en fonction des taux de progression et des impacts lies aux changements. 

Les mesures et les previsions sont partagees avec les parties prenantes du projet via des graphiques de tendance 
(radiateurs d'information) afin de communiquer les progres, de partager les problemes, de favoriser les activites 
d’ameliorations continues et de gerer les attentes des parties prenantes. 


X3.3.5 GROUPE DE PROCESSUS DE CLOTURE 

Le groupe de processus de cloture comprend les processus permettant de realiser ou de clore formellement un 
projet, une phase ou un contrat. Le travail sur des projets iteratifs, adaptatifs et agiles est organise selon un ordre 
de priorite afin d’executer les elements a plus haute valeur commerciale en premier. Par consequent, si le groupe de 
processus de cloture clot prematurement un projet ou une phase, il y a de fortes chances pour qu’une certaine valeur 
commerciale utile ait deja ete generee. La cloture prematuree n'est ainsi pas tant un echec en termes de couts non 
recuperables mais permet plutot d’obtenir des avantages plus immediats, un effet rapide ou une demonstration de 
faisabilite pour I’entreprise. 
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ANNEXE X4 

RECAPITULATE DES PRINCIPAUX CONCEPTS 
POUR LES DOMAINES DE CONNAISSANCE 


La presente annexe a pour objet de recapituler les sections concernant les Principaux concepts de chacun des 
domaines de connaissance des sections 4 a 13. Elle peut etre utilisee comme une aide par les professionnels du 
management de projet, comme une checklist des objectifs d’apprentissage par les prestataires de formation en 
management de projet ou comme un support pedagogique par les personnes preparant une certification. 


X4.1 PRINCIPAUX CONCEPTS DE LA GESTION DE L’INTEGRATION DU PROJET 

Les principaux concepts de la gestion de I’integration du projet sont, entre autres, les suivants : 

♦ La gestion de ('integration du projet est la responsabilite specifique du chef de projet; elle ne peut etre deleguee 
ni transferee. Le chef de projet est celui qui regroupe les resultats de tous les autres domaines de connaissance 
afin de donner une vue d’ensemble du projet. En fin de compte, il est responsable du projet dans son ensemble. 

♦ Les projets et le management de projet sont integrates par nature, la plupart des taches impliquant plusieurs 
domaines de connaissance. 

♦ Les relations des processus au sein des groupes de processus de management de projet et entre les groupes de 
processus de management de projet sont iteratives. 

♦ La gestion de ('integration du projet consiste a: 

■ veiller a ce que les echeances des livrables du projet, le cycle de vie du projet et le plan de gestion des 
avantages soient alignes; 

■ fournir un plan de management du projet pour atteindre les objectifs du projet; 

■ garantir la creation et (’utilisation des connaissances appropriees dans le cadre du projet; 

■ gerer les performances du projet et les changements apportes aux activites du projet; 

■ prendre des decisions coherentes concernant les principaux changements impactant le projet; 

■ mesurer et maTtriser revolution et prendre les mesures appropriees ; 

■ recueillir, analyser et communiquer les informations du projet aux parties prenantes pertinentes; 

■ executer tout le travail du projet et clore formellement chaque phase, chaque contrat et le projet dans 
son ensemble; 

■ gerer, au besoin, les transitions entre les phases. 
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X4.2 PRINCIPAUX CONCEPTS DE LA GESTION DU PERIMETRE DU PROJET 

Les principaux concepts de la gestion du perimetre du projet sont, entre autres, les suivants : 

♦ Le perimetre peut designer le contenu du produit (les caracteristiques et les fonctions qui definissent un produit, 
un service ou un resultat) ou le perimetre du projet (le travail accompli pour livrer un produit, un service ou un 
resultat presentant les caracteristiques et les fonctions specifies). 

♦ Les cycles de vie du projet peuvent etre predictifs, adaptatifs ou agiles. Dans le cas d’un cycle de vie predictif, 
les livrables du projet sont definis en debut de projet, et tous les changements apportes au niveau du perimetre 
sont geres progressivement. Dans le cas d’un cycle de vie adaptatif ou agile, les livrables sont elabores en de 
multiples iterations au cours desquelles un perimetre detaille est defini et approuve pour chaque iteration au 
debut de ladite iteration. 

♦ Le degre d’achevement du perimetre du projet est mesure par rapport au plan de management du projet. Le 
degre d'achevement du contenu du produit est mesure par rapport aux exigences du produit. 


X4.3 PRINCIPAUX CONCEPTS DE LA GESTION DE L’ECHEANCIER DU PROJET 

Les principaux concepts de la gestion de I’echeancier du projet sont, entre autres, les suivants: 

♦ L'echeancier du projet fournit un plan detaille qui indique comment et quand le projet livrera les produits, les 
services et les resultats definis dans le perimetre du projet. 

♦ Cet outil, qui permet de gerer les attentes des parties prenantes, sert de base a la communication des 
performances. 

♦ Dans la mesure du possible, l’echeancier du projet detaille doit pouvoir etre adapte tout au long du projet en 
fonction des connaissances acquises, de la meilleure comprehension des risques et des activites a valeur ajoutee. 


X4.4 PRINCIPAUX CONCEPTS DE LA GESTION DES COOTS DU PROJET 

Les principaux concepts de la gestion des couts du projet sont, entre autres, les suivants: 

♦ La gestion des couts du projet s’interesse principalement au cout des ressources necessaires pour mener les 
activites du projet, mais elle doit egalementtenir compte de I’effet des decisions du projet sur le cout recurrent 
ulterieur d'utilisation, d'entretien et de support des livrables du projet. 

♦ La fagon de mesurer les couts du projet sera differente d’une partie prenante a une autre et d’un moment a un 
autre. Les exigences des parties prenantes en termes de gestion des couts doivent etre explicitement prises 
en consideration. 

♦ La prevision et I’analyse de la performance financiere attendue du produit du projet peuvent etre effectuees en 
dehors du projet, ou faire partie de la gestion des couts du projet. 
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X4.5 PRINCIPAUX CONCEPTS DE LA GESTION DE LA QUALITE DU PROJET 

Les principaux concepts de la gestion de la qualite du projet sont, entre autres, les suivants: 

♦ La gestion de la qualite du projet porte a la fois sur le management du projet et sur ses livrables. Elle s’applique 
a tous les projets, independamment de la nature de leurs livrables. En revanche, les mesures et les techniques 
relatives a la qualite du produit sont specifiques du type de livrable genere par le projet. 

♦ La qualite et la classe sont deux concepts differents. La qualite est « le degre auquel un ensemble de 
caracteristiques intrinseques satisfait a des exigences »(ISO 9000). 1 La classe est une categorie attribute aux 
livrables ayant la meme utilisation fonctionnelle, mais des caracteristiques techniques differentes. Le chef de 
projet et I’equipe sont responsables de la gestion des compromis permettant de fournir les niveaux requis en 
matiere de qualite et de classe. 

♦ La prevention est preferable a I’inspection. II vaut mieux concevoir la qualite en livrables qu’identifier des 
problemes de qualite lors de I’inspection. Le cout de la prevention des erreurs est generalement bien inferieur au 
cout de leur correction lorsqu'elles sont detectees par une inspection ou en cours d’utilisation. 

♦ II peut etre necessaire que les chefs de projet connaissent les procedures d’echantillonnage, a savoir 
I’echantillonnage par attributs (le resultat est conforme ou non conforme) et I’echantillonnage par variables (le 
resultat est evalue sur une echelle continue qui mesure le degre de conformite). 

♦ De nombreux projets etablissent des limites de tolerance et de controle pour les mesures du projet et du produit. 
Les tolerances (fourchette de resultats acceptables) et les limites de controle (qui identifient les limites de 
variance courante dans un processus ou dans la performance d’un processus statistiquement stable). 

♦ Le cout de la qualite comprend tous les couts encourus au cours de la vie du produit en investissant dans la 
prevention des non-conformites aux exigences, dans revaluation du produit ou du service, pour s'assurer de 
sa conformite aux exigences, et dans les reprises consecutives au non-respect de ces exigences. Le cout de la 
qualite est souvent le probleme du management de programme, du management de portefeuille, du bureau des 
projets (Project Management Office, PMO) ou des operations. 

♦ Le processus de gestion de la qualite le plus efficace est obtenu lorsque la qualite est integree a la planification 
et la conception du projet et du produit, et lorsqu’il existe une culture de la qualite au sein de I'organisation. 
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X4.6 PRINCIPAUX CONCEPTS DE LA GESTION DES RESSOURCES DU PROJET 

Les principaux concepts de la gestion des ressources du projet sont, entre autres, les suivants : 

♦ Les ressources du projet incluent a la fois des ressources materielles (equipement, materiaux, installations et 
infrastructure) et les ressources de I'equipe (des personnes a qui differentes fonctions et responsabilites ont 
ete attributes). 

♦ Differentes qualites et competences sont necessaires pour gerer les ressources de I’equipe en fonction des 
ressources materielles. 

♦ Le chef de projet doit etre a la fois le directeur et le gestionnaire de I'equipe projet et doit s’investir suffisamment 
pour acquerir, gerer, motiver et responsabiliser les membres de I’equipe. 

♦ II doit avoir conscience des facteurs qui influent sur I’equipe, tels que I’environnement de I’equipe, la situation 
geographique des membres de I’equipe, la communication entre les parties prenantes, la gestion des 
changements organisationnels, les politiques internes et externes, les problemes culturels et le caractere unique 
de I’organisation. 

♦ Le chef de projet est tenu de developper les qualites et les competences de I’equipe de maniere proactive tout 
en maintenant et en ameliorant la satisfaction et la motivation de I’equipe. 

♦ La gestion des ressources materielles vise a repartir et a utiliser les ressources materielles necessaires a 
I’achevement efficace du projet. Faute de gestion et martrise efficaces des ressources, le projet aura moins de 
chance d’etre acheve avec succes. 

X4.7 PRINCIPAUX CONCEPTS DE LA GESTION DES COMMUNICATIONS DU PROJET 

Les principaux concepts de la gestion des communications du projet sont, entre autres, les suivants: 

♦ La communication est le processus d’echange d’informations, prevu ou involontaire, entre des personnes 
et/ou des groupes. La communication decrit le moyen par lequel des informations peuvent etre envoyees 
ou regues, soit par I'intermediaire d’activites comme des reunions et des presentations, soit par le biais 
d’elements, tels que des e-mails, des medias sociaux, des projets de rapport ou des documents de projet. 
La gestion des communications du projet concerne a la fois le processus de communication et la gestion 
des activites et elements de communication. 

♦ Une communication efficace cree un pont entre les diverses parties prenantes dont les differences auront 
generalement un impact ou une influence sur I'execution ou le resultat du projet; il est, par consequent, 
essentiel que toute communication soit claire et concise. 

♦ Les activites de communication peuvent etre internes et externes, formelles et informelles, ecrites et orales. 

♦ La communication peut etre dirigee vers le haut a I’intention des parties prenantes de la direction, vers le bas 
a I’intention des membres de I’equipe ou horizontalement vers des homologues. Le format et le contenu du 
message seront adaptes en consequence. 
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♦ La communication se fait consciemment ou inconsciemment par le biais de mots, d’expressions faciales, 
de gestes et d'autres actions. Elle inclut I’elaboration de strategies et de plans prevoyant des elements de 
communication appropries et I’utilisation de competences en vue de renforcer I’efficacite. 

♦ II convient de faire des efforts afin d’eviter les malentendus et la mauvaise communication. En outre, les methodes, 
les messagers et les messages doivent etre selectionnes avec soin. 

♦ Definir I’objet de la communication, comprendre le destinataire de la communication et maTtriser I’efficacite 
permet de garantir une communication efficace. 


X4.8 PRINCIPAUX CONCEPTS DE LA GESTION DES RISQUES DU PROJET 

Les principaux concepts de la gestion des risques du projet sont, entre autres, les suivants : 

♦ Tous les projets sont risques. L'organisation choisit de prendre un risque lie a un projet pour creer de la valeur 
tout en equilibrant le risque et la recompense. 

♦ La gestion des risques du projet vise a identifier les risques qui ne sont pas couverts par d’autres processus du 
management de projet. 

♦ Au sein de chaque projet, le risque existe a deux niveaux : Le risque individuel du projet est un evenement ou 
une condition possible (incertitude) dont la concretisation aurait un impact positif ou negatif sur un ou plusieurs 
objectifs du projet. Le risque global du projet est I’effet de I’incertitude sur I’ensemble du projet, provenant de 
toutes les sources d'incertitude possibles, comme les risques individuels, qui represente I’exposition des parties 
prenantes aux implications des variations, positives ou negatives, des resultats du projet. Les processus de 
gestion des risques du projet concernent les deux niveaux de risque des projets. 

♦ Les risques individuels du projet peuvent avoir un effet positif ou negatif sur les objectifs du projet, le cas 
echeant. Le risque global du projet peut egalement etre positif ou negatif. 

♦ Des risques continueront a se presenter tout au long de la duree de vie du projet. II convient done d’adopter une 
approche iterative pour mener les processus de gestion des risques du projet. 

♦ Afin de gerer les risques de maniere efficace, dans le cadre d’un projet en particulier, I’equipe projet doit connaitre 
le niveau d’exposition aux risques acceptable pour poursuivre les objectifs du projet. Ce niveau est defini par 
des seuils de risque mesurables qui refletent I’appetence au risque de l'organisation et des parties prenantes 
du projet. 
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X4.9 PRINCIPAUX CONCEPTS DE LA GESTION DES APPROVISIONNEMENTS DU PROJET 


Les principaux concepts de la gestion des approvisionnements du projet sont, entre autres, les suivants : 

♦ Afin de prendre des decisions intelligentes concernant les contrats et les relations contractuelles, le chef de 
projet doit bien connaTtre le processus d’approvisionnement. 

♦ L’approvisionnement implique des accords qui decrivent la relation entre un acheteur et un vendeur. Ces 
accords peuvent etre simples ou complexes. L'approche de I’approvisionnement doit refleter ce niveau de 
complexity Un accord peut etre un contrat, un accord de niveau de service, une entente, un memorandum 
d’accord ou un bon de commande. 

♦ Les accords doivent respecter le droit des contrats local, national et international. 

♦ Le chef de projet doit s’assurer que tous les approvisionnements satisfont aux besoins specifiques du projet, 
tout en travaillant avec des specialistes de I’approvisionnement afin de garantir le respect des politiques de 
I'organisation. 

♦ Le caractere juridiquement contraignant d’un accord signifie qu’il fera I’objet d’un processus d’approbation 
plus large, impliquant souvent le service juridique, afin de garantir qu’il decrit bien les produits, services 
ou resultats que le vendeur s’engage a fournir, conformement aux lois et regimentations en matiere 
d’approvisionnement. 

♦ Un projet complexe peut impliquer la gestion simultanee ou sequentielle de plusieurs contrats. La relation entre 
acheteur et vendeur peut exister a differents niveaux dans un projet donne, et entre des organisations internes 
et externes a I’organisation acheteuse. 


X4.10 PRINCIPAUX CONCEPTS DE LA GESTION DES PARTIES PRENANTES DU PRO JET 

Les principaux concepts de la gestion des parties prenantes du projet sont, entre autres, les suivants : 

♦ Chaque projet comporte des parties prenantes susceptibles d’affecter le projet, ou d’etre affectees par celui-ci 
de fagon positive ou negative. Certaines parties prenantes peuvent avoir un impact limite sur le travail ou les 
resultats du projet; d’autres peuvent avoir une influence significative sur celui-ci et sur les resultats que I'on 
en attend. 

♦ La capacite du chef de projet et de I’equipe a correctement identifier et mobiliser ces parties prenantes de 
maniere appropriee peut faire la difference entre le succes et I’echec. 

♦ Pour augmenter les chances de succes, le processus d’identification et de mobilisation des parties prenantes 
doit commencer le plus tot possible apres I’approbation de la charte du projet, la designation du chef de projet 
et la creation de I'equipe. 

♦ La cle d’une mobilisation efficace des parties prenantes consiste a privilegier une communication continue 
avec toutes les parties prenantes. La satisfaction des parties prenantes doit etre identifiee et geree comme 
un objectif principal du projet. 

♦ Le processus d’identification et de mobilisation des parties prenantes pour le bon deroulement du projet est 
iteratif et doit etre regulierement revu et mis a jour, en particulier lorsque le projet entre dans une nouvelle 
phase, ou en cas de changements significatifs au sein de I’organisation ou de la communaute plus large des 
parties prenantes. 
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ANNEXE X5 

RECAPITULATE DES CONSIDERATIONS RELATIVES 
A L’ADAPTATION POUR LES DOMAINES DE CONNAISSANCE 


La presente annexe a pour objet de recapituler les sections Considerations relatives a I’adaptation de chacun des 
domaines de connaissance des sections 4 a 13. Parce que chaque projet est unique, ces informations peuvent etre 
utilisees pour aider les professionnels a determiner la methode d’adaptation des processus, des donnees d’entree, 
des outils, des techniques et des donnees de sortie pour un projet. Ces informations peuvent egalement permettre de 
determiner le degre de rigueur qu’il convient d’appliquer aux differents processus dans un domaine de connaissance. 


X5.1 GESTION DE L’INTEGRATION DU PROJET 

Parmi les considerations relatives a I'adaptation en matiere de gestion de I’integration du projet, on peut citer les 
elements suivants: 

♦ Cycle de vie du projet. Qu’est-ce qu’un cycle de vie du projet approprie ? Quelles phases doivent composer le 
cycle de vie du projet ? 

♦ Cycle de vie du developpement. Quel cycle de vie et quelle approche de developpement sont appropries pour 
le produit, le service ou le resultat ? L’approche appropriee est-elle plutot predictive ou adaptative ? Dans le 
cas adaptatif, le produit doit-il etre developpe de maniere incrementielle ou iterative ? Une approche hybride 
est-elle meilleure ? 

♦ Approches de gestion. Quels sont les processus de gestion les plus efficaces au vu de la culture organisationnelle 
et de la complexity du projet ? 

♦ Gestion des connaissances. Comment seront gerees les connaissances dans le cadre des projets afin de 
favoriser un environnement de travail collaboratif ? 

♦ Changement. Comment sera gere le changement dans le cadre du projet ? 

♦ Gouvernance. Quels comites de martrise, autres comites et parties prenantes font partie du projet ? Quelles sont 
les exigences en matiere de communication de I'etat du projet ? 

♦ Retour d’experience. Quelles informations doivent etre recueillies tout au long et a la fin du projet ? Comment 
les donnees historiques et le retour d’experience pourront-ils beneficier aux projets futurs ? 

♦ Benefices. Quand et comment les benefices doivent-ils etre communiques : a la fin du projet ou a la fin de 
chaque iteration ou phase ? 
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X5.2 GESTION DU PERIMETRE DU PROJET 


Parmi les considerations relatives a I’adaptation en matiere de gestion du perimetre du projet, on peut citer les 
elements suivants: 

♦ Gestion des connaissances et des exigences. L’organisation dispose-t-elle de systemes de gestion des 
exigences et des connaissances formels ou informels ? Quelles directives le chef de projet devrait-il etablir pour 
que les exigences puissent etre reutilisees ulterieurement ? 

♦ Validation et maitrise. L'organisation a-t-elle etabli des politiques internes, des procedures et des directives de 
validation et de maitrise formelles ou informelles ? 

♦ Utilisation de I’approche agile. L’organisation utilise-t-elle des approches agiles pour manager les projets ? 
L’approche de developpement est-elle iterative ou incrementielle ? A-t-on fait appel a une approche predictive ? 
Une approche hybride pourrait-elle etre efficace ? 

♦ Gouvernance. L’organisation a-t-elle etabli des politiques, des procedures et des directives de gouvernance et 
d’audit formelles ou informelles ? 


X5.3 GESTION DE L’ECHEANCIER DU PROJET 

Parmi les considerations relatives a I'adaptation en matiere de gestion de I’echeancier du projet, on peut citer les 
elements suivants: 

♦ Approche du cycle de vie. Quelle est I’approche du cycle de vie la plus appropriee offrant un echeancier detaille ? 

♦ Duree et ressources. Quels facteurs influent sur les durees (comme une correlation entre les ressources 
disponibles et leur productivity) ? 

♦ Dimensions du projet. Comment la complexity du projet, I’incertitude technologique, la nouveaute du produit, le 
suivi de la cadence ou de I'avancement (comme la gestion de la valeur acquise, le pourcentage d’avancement, 
les indicateurs rouge-jaune-vert [feu tricolore]) influent-ils sur le niveau de maitrise souhaite ? 

♦ Soutien technologique. La technologie est-elle utilisee pour elaborer, enregistrer, transmettre, recevoir et 
conserver les informations du modele d’echeancier du projet ? Est-elle immediatement accessible ? 
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X5.4 GESTION DES COUTS DU PROJET 


Parmi les considerations relatives a I'adaptation en matiere de gestion des couts du projet, on peut citer les 
elements suivants: 

♦ Gestion des connaissances. L’organisation dispose-t-elle d’une archive formelle immediatement accessible 
pour les bases de donnees financieres et la gestion des connaissances, que le chef de projet esttenu d’utiliser ? 

♦ Estimation et budgetisation. L'organisation a-t-elle mis en place des politiques, des procedures et des directives, 
formelles et informelles, relatives a la budgetisation et a I'estimation des couts ? 

♦ Gestion de la valeur acquise. L'organisation utilise-t-elle la gestion de la valeur acquise pour gerer ses projets ? 

♦ Utilisation de I’approche agile. L'organisation utilise-t-elle les methodologies agiles pour gerer ses projets ? 
Dans quelle mesure ces methodologies influent-elles sur I’estimation des couts ? 

♦ Gouvernance. L’organisation a-t-elle etabli des politiques, des procedures et des directives de gouvernance 
et d’audit formelles ou informelles ? 


X5.5 GESTION DE LA QUALITE DU PROJET 

Parmi les considerations relatives a I’adaptation en matiere de gestion de la qualite du projet, on peut citer les 
elements suivants: 

♦ Respect des politiques et audit. Quelles politiques et procedures qualite ^organisation a-t-elle mises en place ? 
Quels outils, techniques et modeles de qualite l’organisation utilise-t-elle ? 

♦ Respect des standards et des regimentations. Des standards de qualite specifiques du secteur doivent-ils 
etre appliques ? Des contraintes reglementaires, juridiques ou d’un regulateur specifiques doivent-elles etre 
prises en compte ? 

♦ Amelioration continue. Comment I’amelioration de la qualite est-elle geree dans le projet ? Est-elle geree au 
niveau de l’organisation ou au niveau du projet ? 

♦ Engagement des parties prenantes. Les parties prenantes et les fournisseurs beneficient-ils d’un 
environnement collaboratif ? 
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X5.6 GESTION DES RESSOURCES DU PROJET 


Parmi les considerations relatives a I'adaptation en matiere de gestion des ressources du projet, on peut citer les 
elements suivants: 

♦ Diversite. Quelle experience I’equipe a-t-elle de la diversity ? 

♦ Emplacement physique. Ou se trouvent les membres de I’equipe et les ressources materielles ? 

♦ Ressources propres au secteur. Quelles sont les ressources speciales necessaires au secteur ? 

♦ Recrutement des membres de I’equipe. Comment seront recrutes les membres de I’equipe pour le projet ? 
Les membres de I'equipe travailleront-ils a temps plein ou a temps partiel sur le projet ? 

♦ Developpement et gestion de I’equipe. Comment le developpement de I’equipe est-il gere dans le cadre du 
projet ? Existe-t-il des outils organisationnels pour gerer le developpement de I’equipe ? Faut-il en etablir de 
nouveaux ? L'equipe devra-t-elle etre formee a la gestion de la diversite ? 

♦ Approches du cycle de vie. Quelle approche du cycle de vie sera utilisee pour le projet ? 


X5.7 GESTION DES COMMUNICATIONS DU PROJET 

Parmi les considerations relatives a I’adaptation en matiere de gestion des communications du projet, on peut citer 
les elements suivants: 

♦ Parties prenantes. Les parties prenantes sont-elles internes ou externes a I’organisation, ou les deux ? 

♦ Emplacement physique. Ou se trouvent les membres de I’equipe ? Sont-ils regroupes en un meme lieu ? 
Se situent-ils dans la meme region geographique ? Sont-ils repartis sur plusieurs fuseaux horaires ? 

♦ Technologie de communication. Quelles sont les technologies disponibles pour elaborer, enregistrer, transmettre, 
recuperer, suivre et conserver les supports de communication ? Quelles sont les technologies les mieux adaptees 
et les plus rentables pour communiquer avec les parties prenantes ? 

♦ Langue. La langue est I’un des principaux facteurs a prendre en compte lors des activites de communication. 
Une ou plusieurs langues sont-elles utilisees ? La complexity due a I’appartenance de membres de I’equipe a 
differents groupes de langues a-t-elle ete prise en compte ? 

♦ Gestion des connaissances. L'organisation dispose-t-elle d’une archive officielle en matiere de gestion des 
connaissances ? Cette archive est-elle utilisee ? 
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X5.8 GESTION DES RISQUES DU PROJET 


Parmi les considerations relatives a I’adaptation en matiere de gestion des risques du projet, on peut citer les 
elements suivants: 

♦ Taille du projet. La taille du projet en termes de budget, de duree, de perimetre ou de taille de I’equipe necessite- 
t-elle une approche plus detaillee de la gestion des risques ? Ou est-elle suffisamment petite pour justifier un 
processus de risque simplifie ? 

♦ Complexity du projet. Les hauts niveaux en matiere d’innovation, de nouvelles technologies, d’accords 
commerciaux, d'interfaces ou de dependences externes qui augmentent la complexity du projet exigent-ils une 
approche de risque solide ? Ou le projet est-il suffisamment simple pour qu’un processus de risque reduit suffise ? 

♦ Importance du projet. Quelle est I’importance strategique du projet ? Le niveau de risque de ce projet a-t-il 
augmente du fait qu’il vise a produire des opportunites d’avancees majeures, qu’il traite des elements importants 
pour la performance de I'organisation ou qu’il implique une innovation de produit majeure ? 

♦ Approche de developpement. S'agit-il d’un projet type waterfall ou les processus de risque peuvent etre suivis 
de maniere sequentielle et iterative, ou le projet suit-il une approche agile ou le risque est traite au debut de 
chaque iteration et en cours d’execution ? 


X5.9 GESTION DES APPROVISIONNEMENTS DU PROJET 

Parmi les considerations relatives a I’adaptation en matiere de gestion des approvisionnements du projet, on peut 
citer les elements suivants : 

♦ Complexity del’approvisionnement.Existe-t-ilunapprovisionnement principal ouplusieurs approvisionnements 
a des moments varies avec differents vendeurs qui augmentent la complexity des approvisionnements ? 

♦ Emplacement physique. Les acheteurs et les vendeurs se trouvent-ils au meme endroit ou raisonnablement 
proches ou dans differents fuseaux horaires, pays ou continents ? 

♦ Gouvernance et environnement reglementaire. Les lois et regimentations locales concernant les activites 
d’approvisionnementsont-elles integrees dans les politiques d’approvisionnement de I'organisation ? Quelle est 
I’influence sur les exigences de controle des contrats ? 

♦ Disponibilite des cocontractants. Des cocontractants sont-ils disponibles et capables d’executer le travail ? 
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X5.10 GESTION DES PARTIES PRENANTES DU PROJET 

Parmi les considerations relatives a I’adaptation en matiere de gestion des parties prenantes du projet, on peut citer 
les elements suivants: 

♦ Diversity des parties prenantes. Quel est le nombre de parties prenantes ? Dans quelle mesure la culture au 
sein de la communaute des parties prenantes est-elle diversifiee ? 

♦ Complexity des relations entre les parties prenantes. Dans quelle mesure les relations au sein de la 
communaute des parties prenantes sont-elles complexes ? Plus une partie prenante ou un groupe de parties 
prenantes participe a des reseaux, plus la partie prenante risque de recevoir des reseaux d’information et de 
disinformation complexes. 

♦ Technologie de communication. Quelle est la technologie de communication disponible ? Quels mecanismes 
de support ont ete mis en place pour garantir le meilleur resultat technologique ? 
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ANNEXE X6 

OUTILS ET TECHNIQUES 


X6.1 INTRODUCTION 

La Sixieme edition du Guide PMBOK® presente les outils et techniques d’une autre fagon par rapport aux editions 
precedentes. Cette edition regroupe les outils et techniques en fonction de leur finalite, le cas echeant. Le nom du groupe 
deed I’objectif de la tache requise. Les outils et techniques dans le groupe represented les differentes methodes 
d’atteindre cet objectif. Par exemple, la collecte de donnees est un groupe dont I’objectif vise a recueillir des donnees et 
des informations. Le brainstorming, les entretiens et une etude de marche font partie des techniques qui peuvent etre 
utilisees pour collecter des donnees et des informations. 

Cette approche reflete I’importance que la Sixieme edition accorde a I'adaptation des informations presentees dans 
le Guide PMBOK ® en fonction des besoins de I’environnement, de la situation, de I’organisation et du projet. 

La Sixieme edition du Guide PMBOK ® repertorie 132 outils et techniques individuels. II ne s'agit pas des seuls outils 
et techniques pouvant etre utilises pour gerer un projet. Ils represented les outils et techniques qui sont considers 
comme de bonnes pratiques, pour la plupart des projets et la plupart du temps. Certains sont cites une seule fois, tandis 
que d'autres apparaissent de nombreuses fois dans le Guide PMBOK®. 

Pour aider les professionnels a identifier les cas dans lesquels utiliser ces outils et techniques specifiques, la presente 
annexe recense chaque outil et chaque technique, le groupe auquel ils appartiennent (le cas echeant) et les processus 
ou ils figured dans le Guide PMBOK®. Le processus oil un outil ou une technique est decrit(e) dans le guide est en 
caracteres gras. Les autres processus ou I’outil ou la technique est recense(e) indiqueront le processus ou ils sont 
deeds. Les processus peuvent donner des details supplementaires sur la fagon dont un outil ou une technique est 
utilise(e) dans un processus particulier. 
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X6.2 GROUPES D’OUTILS ET TECHNIQUES 


Les groupes d’outils et techniques suivants sont utilises dans tout le Guide PMBOK®: 

♦ Techniques de collecte des donnees. Techniques utilisees pour collecter des donnees et des informations 
aupres de diverses sources. II existe neuf outils et techniques de collecte des donnees. 

♦ Techniques d’analyse des donnees. Techniques utilisees pour organiser, analyser et evaluer des donnees et 
des informations. II existe 27 outils et techniques d’analyse des donnees. 

♦ Techniques de representation des donnees. Representations graphiques ou autres methodes utilisees pour 
communiquer des donnees et des informations. II existe 15 outils et techniques de representation des donnees. 

♦ Techniques de prise de decision. Techniques utilisees pour definir une ligne d'action a partir de plusieurs 
alternatives. II existe deux outils et techniques de prise de decision. 

♦ Competences en communication. Competences utilisees pour le transfert des informations entre les parties 
prenantes. II existe deux outils et techniques lies aux competences en communication. 

♦ Competences interpersonnelles et d’equipe. Competences utilisees pour diriger une equipe de maniere 
efficace et interagir avec ses membres et d’autres parties prenantes. II existe 17 outils et techniques lies aux 
competences interpersonnelles et d’equipe. 

II existe 60 outils et techniques isoles. 

Tableau X6-1. Classement et indice des outils et techniques 


r 

Outil et 
technique 

Domaine de connaissance A 

Integration 

Peri metre 

Echeancier 

Cout 

Qualite 

Ressource 

Communication 

Risque 

Approvisionne- 

ment 

Partie prenante 

Outils et techniques de collecte des donnees 

Benchmarking 


5.2 



8.1 





13.2 

Brainstorming 

4.1, 4.2 

5.2 



8.1 



11.2 


13.1 

Fiches de controle 





8.3 






Checklists 

4.2 




8.2, 8.3 



11.2 



Groupes de 
discussion 

4.1, 4.2 

5.2 









Entretiens 

4.1, 4.2 

5.2 



8.1 



11.2, 

11.3, 

11.4, 

11.5 



Etude de marche 









12.1 


Questionnaires et 
enquetes 


5.2 








13.1 

Echantillonnage 

statistique 





8.3 





-d 
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Tableau X6-1. Classement et indice des outils et techniques (suite) 
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Tableau X6-1. Classement et indice des outils et techniques (suite) 
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689 



































































Tableau X6-1. Classement et indice des outils et techniques (suite) 
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Tableau X6-1. Classement et indice des outils et techniques (suite) 
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Tableau X6-1. Classement et indice des outils et techniques (suite) 
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Tableau X6-1. Classement et indice des outils et techniques (suite) 



A Les entrees en gras indiquent les numeros de section des processus ou un outil ou une technique est decrit(e). 
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GLOSSAIRE 


1. INCLUSIONS ET EXCLUSIONS 

Ce glossaire comprend des termes : 

♦ qui s’appliquent exclusivement, ou presque, au management de projet (exemples : enonce du contenu du projet, 
lot de travail, organigramme des travaux du projet, methode du chemin critique, etc.), 

♦ qui ne s’appliquent pas exclusivement au management de projet, mais dont le sens est different ou plus restreint 
qu’en usage courant (exemple : date de debut au plus tot). 

II ne contient pas, en general: 

♦ de termes propres a un domaine d’application donne, 

♦ de termes dont I’utilisation en management de projet ne differe pas essentiellement de I’usage courant 
(exemple : jour calendaire, retard), 

♦ d’expressions dont la signification correspond clairement a celles combinees de leurs differents elements, 

♦ de variantes, lorsque leur signification se deduit du terme de reference, 

♦ de termes utilises une seule fois qui ne sont pas essentiels a la comprehension du texte. II peut s'agir d’une 
liste d’exemples donttous les termes ne seraient pas definis dans ce glossaire. 
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2. ACRONYMES COURANTS 


Francais 

Anglais 

Acronyme 

Description 

Description 

Acronyme 


Appel asoumissionner 

invitation for bid 

IFB 


Appel d’offre 

request for proposal 

RFP 

BAC 

Budget a terminaison 

budget at completion 

BAC 


Comite de martrise des changements 

change control board 

CCB 

FPEPA 

Contrat a prix ferme avec indexation 
des prix 

fixed price with economic price 
adjustment 

FPEPA 


Contrat a prix ferme avec interessement 

fixed price incentive fee 

FPIF 


Contrat a prix ferme et definitif 

firm fixed price 

FFP 


Contrat en regie 

time and material contract 

T&M 


Contrat en regie avec honoraires fixes 

cost plus fixed fee 

CPFF 


Contrat en regie avec interessement 

cost plus incentive fee 

CPIF 


Contrat en regie avec prime 
a la performance 

cost plus award fee 

CPAF 

PMBOK 

Corpus des connaissances en 
management de projet 

Project Management Body of Knowledge 

PMBOK 


Cout de la qualite 

cost of quality 

COQ 

ETC 

Coutdu reste afaire 

estimate to complete 

ETC 

EAC 

Cout estime a terminaison 

estimate at completion 

EAC 

AC 

Cout reel 

actual cost 

AC 


Date de debut au plus tard 

late start date 

LS 


Date de debut au plus tot 

early start date 

ES 


Date de fin au plus tard 

late finish date 

LF 


Date de fin au plus tot 

early finish date 

EF 


Demande d’information 

request for information 

RFI 


Demande de devis 

request for quotation 

RFQ 

VAC 

Ecart a terminaison 

variance at completion 

VAC 
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Frangais 

Anglais 

Acronyme 

Description 

Description 

Acronyme 

C V 

Ecart de cout 

cost variance 

C V 

S V 

Ecart de delais 

schedule variance 

S V 


Enonce des travaux 

statement of work 

sow 


Gestion de la valeur acquise 

earned value management 

EVM 

CPI 

Indice de performance des couts 

cost performance index 

CPI 

SPI 

Indice de performance des delais 

schedule performance index 

SPI 

DD 

Liaison debut-debut 

start-to-start 

SS 

DF 

Liaison debut-fin 

start-to-finish 

SF 

FD 

Liaison fin-debut 

finish to start 

FS 

FF 

Liaison fin-fin 

finish-to-finish 

FF 


Matrice des responsabilites 

responsibility assignment matrix 

RAM 


Methode des antecedents 

precedence diagramming method 

PDM 


Methode du chemin critique 

critical path method 

CPM 


Niveau d’effort 

level of effort 

LOE 


Organigramme des risques 

risk breakdown structure 

RBS 

WBS 

Organigramme des travaux du projet 

work breakdown structure 

WBS 


Organigramme fonctionnel 

organizational breakdown structure 

OBS 

QFD 

quality function deployment 

quality function deployment 

QFD 

RACI 

Realisateur-Approbateur-Consulte- 

Informe 

responsible, accountable, consult, 
and inform 

RACI 

SWOT 

SWOT (strengths, weaknesses, 
opportunities, and threats) Forces, 
faiblesses, opportunity, menaces 

strengths, weaknesses, opportunities, 
and threats 

SWOT 

EV 

Valeur acquise 

earned value 

EV 

PV 

Valeur planifiee 

planned value 

PV 
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3. DEFINITIONS 


Un assez grand nombre de termes definis ci-dessous ont une definition plus large, et quelquefois differente, dans les 
dictionnaires courants. Dans certains cas, une entree de ce glossaire est composee de plusieurs termes (par exemple, 
analyse des causes fondamentales). 

Acceptation du risque / Risk Acceptance. Strategie de reponse aux risques par laquelle I'equipe projet decide 
de reconnartre le risque et de ne pas agir a moins que le risque n’arrive. 

Accord de niveau de service (Service Level Agreement, SLA) / Service Level Agreement (SLA). Contrat conclu 
entre un prestataire de services (interne ou externe) et I’utilisateur final qui definit le niveau de service attendu 
d’un fournisseur. 

Accords / Agreements. Tout document ou communication qui definit les intentions initiales d’un projet. Cela peut 
prendre la forme d’un contrat, d’un protocole d'accord (PA), de lettres d'entente, d’accords verbaux, d’un courriel, etc. 

Actifs organisationnels / Organizational Process Assets. Plans, processus, politiques internes, procedures et bases 
de connaissances qui sont specifiques et utilises par I'organisation realisatrice. 

Action corrective / Corrective Action. Activite executee dans I'intention de realigner la performance d’execution 
du projet avec le plan de management du projet. 

Action preventive / Preventive Action. Activite executee dans I’intention de s’assurer que la performance future 
du travail du projet sera alignee sur le plan de management du projet. 

Activite / Activity. Une partie distincte et planifiee du travail realise dans le cadre d’un projet. 

Activite critique / Critical Path Activity. Toute activite situee sur le chemin critique dans I’echeancier d’un projet. 

Activite predecesseur (ou activite antecedente) / Predecessor Activity. Une activite qui precede logiquement une 
activite dependante dans un echeancier. 

Activite successeur / Successor Activity. Activite dependante qui vient logiquement apres une autre activite dans 
un echeancier. 

Activites sur noeuds / Activity-on-Node (AON). Voir Methode des antecedents. 

Adaptation / Tailoring. Technique determinant la combinaison appropriee des processus, des donnees d’entree, des 
outils, des techniques, des donnees de sortie et des phases du cycle de vie en vue de manager un projet. 

Alea / Contingency. Un evenement ou une circonstance pouvant avoir une incidence sur I’execution du projet et qui 
peut etre pris en compte grace a une reserve. 

Analyse cout-benefice / Cost-Benefit Analysis. Un outil d’analyse financiere utilise pour determiner les benefices que 
presente un projet par rapport a ses couts. 

Analyse de la reserve / Reserve Analysis. Technique analytique utilisee pour determiner les caracteristiques et les 
relations essentielles entre les elements dans le plan de management du projet, afin de definir pour ce projet une 
reserve pour la duree de I’echeancier, le budget, I’estimation du cout ou les fonds prevus. 

Analyse de la tendance / Trend Analysis. Technique analytique faisant appel a des modeles mathematiques pour 
prevoir les resultats futurs sur la base de resultats historiques. 
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Analyse de regression / Regression Analysis. Technique analytique qui etudie une serie de variables d’entree par 
rapport a leurs resultats correspondants en sortie, afin d’elaborer un modele mathematique ou un lien statistique. 

Analyse de sensibilite / Sensitivity Analysis. Technique d'analyse qui determine les risques individuels du projet ou 
d'autres sources d’incertitude ayant le plus important impact potentiel sur les resultats du projet, en mettant en relation 
les variations de ces derniers avec celles des elements d’un modele d’analyse quantitative des risques. 

Analyse decisionnelle multicritere / Multicriteria Decision Analysis. Technique qui fait appel a une matrice de 
decision visant afournir une approche analytique systematique, afin d’etablir des criteres, tels que les niveaux de risque, 
I’incertitude et la valorisation, pour evaluer et classer de nombreuses idees. 

Analyse des alternatives / Alternative Analysis. Technique utilisee pour evaluer et selectionner des options ou 
approches identifies d’execution et de realisation du travail du projet. 

Analyse des causes originelles / Root Cause Analysis. Technique analytique permettant de determiner la raison 
sous-jacente fondamentale qui genere un ecart, un defaut ou un risque. Une meme cause originelle peut etre sous- 
jacente a plusieurs ecarts, defauts ou risques. 

Analyse des ecarts / Variance Analysis. Technique servant a determiner la cause et le degre de difference entre la 
reference de base et la performance reelle. 

Analyse des exigences en communication / Communication Requirements Analysis. Technique analytique visant 
a determiner les besoins en information des parties prenantes du projet grace a des entretiens, a des ateliers, a I'etude 
des retours d’experience tires des projets anterieurs, etc. 

Analyse des listes de controle / Checklist Analysis. Technique permettant de passer systematiquement en revue le 
materiel a I'aide d’une liste destinee a en controler I’exactitude et I'exhaustivite. 

Analyse des parties prenantes / Stakeholder Analysis. Technique qui consiste a recueillir et a analyser 
systematiquement les informations quantitatives et qualitatives afin de determiner quels interets particuliers doivent 
etre pris en compte tout au long du projet. 

Analyse du diagramme de reseau / Schedule Network Analysis. Technique d’identification des dates de debut au plus 
tot et au plus tard, ainsi que des dates de fin au plus tot et au plus tard, pour la partie inachevee des activites du projet. 

Analyse du produit / Product Analysis. Pour les projets dont I’element livrable est un produit, c’est un outil permettant 
de definir le perimetre, ce qui signifie generalement poser des questions a propos d’un produit etformuler des reponses 
pour decrire I'utilisation, les caracteristiques et d’autres aspects pertinents de ce qui va etre fabrique. 

Analyse« Make-or-Buy»/ Make-or-Buy Analysis. Processus consistant a reunir et a organiser les donnees sur les 
exigences du produit et a les analyser par rapport a des alternatives disponibles, y compris I’achat ou la fabrication 
interne du produit. 

Analyse par arbre de decision / Decision Tree Analysis. Technique de schematisation et de calcul pour evaluer les 
incidences d’une chaine de plusieurs options en presence d’incertitude. 

Analyse par scenario / What-lf Scenario Analysis. Processus devaluation de scenarii afin de predire leurs effets 
sur les objectifs du projet. 

Analyse SWOT / SWOT Analysis. Analyse des forces, faiblesses, opportunites et menaces d’une organisation, d’un 
projet ou d’une option. 
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Appel a soumissionner (Invitation tor Bid, IFB) / Invitation for Bid (IFB). En regie generate, equivalent a un appel 
d’offres. Cependant, dans certains domaines d'application, I’appel d’offres peut avoir une signification plus restreinte 
ou plus specifique. 

Appel d’offres (Request for Proposal, RFP) / Request for Proposal (RFP). Type de document d’approvisionnement 
utilise pour solliciter des propositions de la part de fournisseurs potentiels de produits ou de services. Dans certains 
domaines d’application, il peut avoir une signification plus restreinte ou plus specifique. 

Appetence au risque / Risk Appetite. Degre d’incertitude qu’une organisation ou une personne est disposee 
a accepter dans ^anticipation d’un avantage. 

Apprentissage organisationnel / Organizational Learning. Discipline relative a la maniere dont les personnes, 
les groupes et les organisations acquierent des connaissances. 

Approche de developpement / Development Approach. Methode utilisee pour creer un produit, un service ou un 
resultat et le faire evoluer tout au long du cycle de vie d’un projet. II peut s'agir d’une methode predictive, iterative, 
incrementielle, agile ou hybride. 

Archive des retours d’experience / Lessons Learned Repository. Ensemble d'informations historiques sur les retours 
d’experience au cours des projets. 

Attenuation des risques / Risk Mitigation. Strategie de reponse aux risques par laquelle I'equipe projet agit pour 
reduire la probabilite d’occurrence ou I’impact d’une opportunity 

Attributs des activites / Activity Attributes. Divers attributs associes a chaque activite de I’echeancier et pouvant 
figurer dans la liste d’activites. Les attributs d’une activite comprennent le code de I’activite, les activites predecesseurs 
etsuccesseurs, les liens logiques, les decalages avec avance et les decalages avec retard, les exigences en ressources, 
les dates imposees, les contraintes et les hypotheses. 

Audit de risques / Risk Audit. Type d’audit utilise pour evaluer I’efficacite des processus de gestion des risques. 

Audits d’approvisionnement / Procurement Audits. Revue de I’exhaustivite, de I'exactitude et de I’efficacite des 
contrats et des processus de passation de contrat. 

Audits qualite / Quality Audits. Processus structure et independant permettant de determiner si les activites du projet 
sont conformes aux politiques, aux processus et aux procedures de I’organisation et du projet. 

Autorite / Authority. Droit d’affecter des ressources au projet, de depenser des fonds, de prendre des decisions ou de 
donner des approbations. 

Avance / Lead. Duree dont une activite successeur peut etre avancee par rapport a une activite predecesseur. 

Base des estimations / Basis of Estimates. Document de support donnant les grandes lignes des informations utilisees 
pour etablir les estimations du projet telles que les hypotheses, les contraintes, le niveau de detail, les fourchettes de 
valeurs et les niveaux de confiance. 

Benchmarking / Benchmarking. Etude comparative de pratiques courantes ou envisagees, telles que les processus et 
les operations, avec celles d’organisations comparables dans le but d’identifier les meilleures pratiques, de trouver des 
idees d'ameliorations et de fournir une reference pour la mesure de performance. 

Besoin en financement du projet / Project Funding Requirements. Couts previsionnels du projet a payer qui sont 
derives de la reference de base des couts pour les exigences totales ou periodiques, y compris les depenses prevues 
et les dettes anticipees. 


700 


Troisieme partie - Glossaire 



Besoins en ressources / Resource Requirements. Les types et les quantites de ressources necessaires a chacune 
des activites d’un lot de travail. 

Budget / Budget. Estimation approuvee du projet, d’un element de I’organigramme des travaux du projet ou d’une 
activite de I'echeancier. 

Budget a terminaison (Budget at Completion, BAC) / Budget at Completion (BAC). La somme de tous les budgets 
etablis pour le travail a effectuer. 

Bureau des Projets (Project Management Office, PMO) / Project Management Office (PMO). Structure de 
management qui normalise les processus de gouvernance lies a des projets et facilite le partage des ressources, des 
methodologies, des outils et des techniques. 

Business Case / Business Case. Le business case est une etude de faisabilite economique documentee destinee 
a s'assurer de la viabilite d’un investissement. II servira de base pour autoriser I’initialisation d’un projet. 

Calcul au plus tard / Backward Pass. Technique de la methode du chemin critique pour le calcul des dates de debut 
et de fin au plus tard en procedant a rebours sur le modele de I’echeancier a partir de la date de fin du projet. 

Calcul au plus tot / Forward Pass. Technique de la methode du chemin critique pour le calcul des dates de debut et 
de fin au plus tot en procedant vers I’aval sur le modele de I'echeancier a partir de la date de debut du projet ou d’un 
point donne dans le temps. 

Calendrier des ressources / Resource Calendar. Calendrier qui specifie le nombre de jours ouvres et les rotations 
d’equipe durant lesquels chaque ressource specifique est disponible. 

Calendrier du projet / Project Calendar. Un calendrier qui identifie les jours ouvrables et les rotations d’equipe qui sont 
disponibles pour les activites de I’echeancier. 

Categorie de risques / Risk Category. Groupe de causes potentielles de risque. 

Categorisation des risques / Risk Categorization. Organisation par source de risque (par exemple, en utilisant 
I'organigramme des risques), par domaine du projet impacte (par exemple, en utilisant le WBS), ou selon toute autre 
categorie utile (par exemple, la phase du projet) en vue de determiner les parties du projet les plus exposees aux effets 
de I’incertitude. 

Centre de Consolidation / Control Account. Point de maTtrise de gestion ou sont integres le perimetre, le budget, le 
cout reel et I’echeancier, et compares a la valeur acquise aux fins de mesure des performances. 

Changement / Change. Modification apportee a un livrable, un element du plan de management du projet ou un 
document de projet formellement approuve. 

Charge de risque / Risk Owner. Personne responsable de la maTtrise du risque, mais aussi de la selection et de 
I’application d’une strategie de reponse aux risques appropriee. 

Charte / Charter. Voir Charte du projet. 

Charte d’equipe / Team Charter. Document qui consigne les directives de fonctionnement, les accords et les valeurs 
de I'equipe et qui definit clairement le minimum acceptable comme comportement des membres de I'equipe projet. 

Charte du projet / Project Charter. Document emis par I'initiateur ou le sponsor du projet, qui en autorise formellement 
I'existence et donne autorite au chef de projet pour affecter des ressources de I'organisation aux activites de ce projet. 
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Checklist de la qualite / Quality Checklists. Aussi appele liste de controle de la qualite. Un outil structure utilise pour 
verifier qu’un ensemble d’etapes requises a ete execute. 

Chef de projet / Project Manager (PM). La personne designee par I'organisation realisatrice pour diriger I’equipe 
chargee de la realisation des objectifs du projet. 

Chemin critique / Critical Path. La sequence d’activites qui represente le chemin le plus long dans le cadre d’un projet 
et qui determine la duree la plus courte possible pour ce projet. 

Chemin du reseau / Network Path. Une sequence d’activites connectees par des liens logiques dans un diagramme 
de reseau du projet. 

Classe / Grade. Categorie ou rang utilise pour distinguer des articles ayant le meme usage fonctionnel mais soumis a 
des exigences de qualite differentes. 

Clore le projet ou la phase / Close Project or Phase. Processus de finalisation de toutes les activites d’un projet, d’une 
phase ou d’un contrat. 

Code WBS / Code of Accounts. Systeme de nomenclature utilise pour identifier chaque element de I’organigramme 
des travaux du projet (WBS). 

Colocalisation / Colocation. Strategie de regroupement de I'equipe projet au meme endroit, afin d’ameliorer la 
communication, les relations de travail et la productivity. 

Comite de maTtrise des changements / Change Control Board (CCB). Groupe officiellement forme et charge de 
passer en revue, d’evaluer, d’approuver, de differer ou de refuser des changements du projet, ainsi que d’enregistrer et 
de communiquer ces decisions. 

Commission / Fee. Benefice d’un fournisseur en tant que composant de sa remuneration. 

Competences en management / Management Skills. Aptitude a planifier, a organiser et a diriger les personnes ou les 
groupes de personnes afin d’atteindre des objectifs specifiques. 

Competences interpersonnelles / Interpersonal Skills. Competences utilisees pour etablir et entretenir des relations 
avec d’autres personnes. 

Competences interpersonnelles et d’equipe / Interpersonal and Team Skills. Competences utilisees pour diriger 
une equipe de maniere efficace et interagir avec ses membres et d’autres parties prenantes. 

Compression de I’echeancier / Schedule Compression. Technique utilisee pour raccourcir la duree de I’echeancier 
sans reduire le perimetre du projet. 

Compression des delais / Crashing. Technique utilisee pour reduire la duree de I’echeancier pour un cout minimum, 
en ajoutant des ressources. 

Condition de declenchement / Trigger Condition. Evenement ou situation qui indique qu’un risque est sur le point de 
se concretiser. 

Conference des soumissionnaires / Bidder Conference. Les reunions avec des fournisseurs potentiels avant la 
preparation d’une soumission ou d’une proposition pour s’assurer que tous les fournisseurs potentiels ont une 
comprehension claire et commune de I'approvisionnement. Egalement appelee conference des fournisseurs, ou 
conference preliminaire a I’offre. 
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Conformite / Conformance. Dans le cadre du systeme de gestion de la qualite, la conformite est un concept general 
visant a produire des resultats qui se situent dans les limites acceptables d’un ecart pour une exigence de qualite. 

Connaissances / Knowledge. Melange d'experiences, de valeurs, de croyances, d’informations contextuelles, d'intuition 
et de perspicacite utilise par les personnes pour comprendre les nouvelles experiences et informations. 

Connaissances explicites / Explicit Knowledge. Connaissances pouvant etre codifiees a I'aide de symboles, tels que 
des mots, des chiffres et des images. 

Connaissances tacites / Tacit Knowledge. Connaissances personnels qui peuvent etre difficiles a exprimer et a 
partager, com me des croyances, des experiences et des intuitions. 

Consolidation d’activites / Summary Activity. Groupe d’activites de I’echeancier apparentees qui sont regroupees et 
affichees comme une activite unique. 

Consolidation des couts / Cost Aggregation. Resultat de I’addition des estimations des couts du niveau inferieur par 
lot de travail, jusqu'a un niveau donne de I'organigramme des travaux du projet ou d’un Centre de consolidation des 
couts donne. 

Contenu du produit / Product Scope. Caracteristiques et fonctions qui caracterisent un produit, un service ou un resultat. 

Contrainte / Constraint. Facteur qui limite les options de realisation d’un projet, d’un programme, d’un portefeuille ou 
d’un processus. 

Contrat / Contract. Un accord d’engagement mutuel par lequel le fournisseur doit fournir le produit, le service ou le 
resultat specifie, en contrepartie duquel I’acheteur doit le payer. 

Contrat a frais remboursables / Cost-Reimbursable Contract. Type de contrat dans lequel un paiement est 
effectue au fournisseur pour les couts reels encourus, majores d’honoraires qui constituent generalement le benefice 
du fournisseur. 

Contrat a prix ferme et definitif / Firm Fixed Price Contract (FFP). Type de contrat a prix forfaitaire ou I'acheteur 
paie au fournisseur un montant determine (fixe par le contrat), quelles que soient les depenses engagees par ce dernier. 

Contrat a prix fixe avec indexation des prix / Fixed Price with Economic Price Adjustment Contract (FPEPA). 

Contrat au forfait, comportant toutefois une clause speciale permettant des revisions finales predefines du prix 
contractuel en raison de changements des conditions initiales, tels que les effets de I’inflation ou les variations des 
couts de matieres premieres. 

Contrat a prix fixe avec interessement / Fixed Price Incentive Fee Contract (FPIF). Type de contrat par lequel 
I’acheteur paie au fournisseur un montant determine (fixe par le contrat), auquel peut s’ajouter un supplement si le 
fournisseur respecte des criteres de performance predefinis. 

Contrat a prix forfaitaire / Fixed-Price Contract. Accord qui etablit les honoraires qui seront verses pour un travail 
dont le perimetre est defini, independamment du cout ou de I'effort requis pour le fournir. 

Contrat en regie (Time and Material Contract, T&M) / Time and Material Contract (T&M). Type de contrat etabli 
sous forme d’accord contractuel hybride, contenant a la fois des aspects des contrats a frais remboursables et des 
contrats a prix forfaitaire. 

Contrat en regie avec honoraires fixes / Cost Plus Fixed Fee Contract (CPFF). Type de contrat a frais remboursables 
dans lequel I'acheteur rembourse au fournisseur les couts autorises (definis contractuellement), et paie en sus des 
honoraires fixes (benefice du fournisseur). 
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Contrat en regie avec interessement / Cost Plus Incentive Fee Contract (CPIF). Type de contrat a frais remboursables 
dans lequel I'acheteur rembourse au fournisseur les couts autorises (definis contractuellement), et paie en sus des 
honoraires calcules en fonction du respect de criteres de performance definis. 

Contrat en regie avec prime a la performance / Cost Plus Award Fee Contract (CPAF). Categorie de contrat qui 
prevoit des paiements au fournisseur pour tous les couts reels legitimes encourus pour le travail acheve, majores d’une 
prime a la performance representant le benefice du fournisseur. 

Convergence des chemins / Path Convergence. Relation dans laquelle une activite de I’echeancier a plus 
d’un predecesseur. 

Corpus des connaissances en management de projet (Guide PMBOK®) / Project Management Body of Knowledge. 

Expression qui designe les connaissances dans le domaine professionnel du management de projet. Le corpus des 
connaissances en management de projet inclut les pratiques classiques, largement appliquees, comme les pratiques 
novatrices en emergence au sein de la profession. 

Correction des defauts / Defect Repair. Activite executee dans I’intention de modifier un produit ou un composant 
d’un produit non conforme. 

Cout de la qualite / Cost of Quality (CoQ). Tous les couts generes tout au long du cycle de vie du produit via 
I’investissement dans des systemes de prevention de la non-conformite aux exigences, devaluation de la conformite du 
produit ou du service aux exigences et d'identification des incapacity a satisfaire aux exigences. 

Cout de reste a faire (Estimate to Complete, ETC) / Estimate to Complete (ETC). Le cout prevu pour terminer tous 
les travaux restants du projet. 

Cout estime a terminaison (Estimate at Completion, EAC) / Estimate at Completion (EAC). L'estimation du cout 
total a terminaison de I’ensemble du travail, exprime comme la somme du cout reel a la date concernee et du Reste a 
faire. Voir aussi Budget a terminaison (BAC) et Cout du reste a faire (ETC). 

Cout reel (Actual Cost, AC) / Actual Cost (AC). Les couts reels encourus pour le travail execute sur une activite, 
pendant une periode de temps specifique. 

Creer le WBS / Create WBS. Le processus qui consiste a subdiviser les livrables et le travail du projet en composants 
plus petits et plus faciles a gerer. 

Criteres / Criteria. Standards, regies ou tests sur lesquels un jugement ou une decision peut etre fonde ou sur la base 
desquels un produit, un service, un resultatou un processus peut etre evalue. 

Criteres d’acceptation / Acceptance Criteria. Un ensemble de conditions qui doivent etre remplies pour que les 
livrables soient acceptes. 

Criteres de selection des sources / Source Selection Criteria. Ensemble d’attributs souhaites par I’acheteur, qu’un 
fournisseur doit satisfaire ou depasser pour etre selectionne pour un contrat. 

Cycle de vie / Life Cycle. Voir Cycle de vie du projet. 

Cycle de vie adaptatif / Adaptive Life Cycle. Cycle de vie d’un projet qui est iteratif ou incrementiel. 

Cycle de vie du produit / Product Life Cycle. Serie de phases qui representent revolution d’un produit, du concept a 
la livraison, la croissance, la maturite et jusqu’a son retrait du marche. 
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Cycle de vie du projet / Project Life Cycle. Serie de phases du projet, depuis son demarrage jusqu’a sa terminaison. 

Cycle de vie incrementiel / Incremental Life Cycle. Cycle de vie d’un projet adaptatif dans le cadre duquel les 
livrables proviennent d’une serie d’iterations qui ajoutent progressivement des fonctionnalites dans une periode de 
temps predetermines. Les livrables comprennent les capacites necessaires et suffisantes pour etre considers comme 
exhaustifs apres I’iteration finale uniquement. 

Cycle de vie iteratif / Iterative Life Cycle. Type de cycle de vie d’un projet dans lequel le perimetre du projet est, en 
regie generate, determine au debut du cycle de vie. Toutefois, I’estimation de la duree et des couts evolue regulierement 
au fur et a mesure que I’equipe projet acquiert une meilleure comprehension du produit. Les iterations developpent le 
produit a travers une serie de cycles repetitifs, tandis que les increments ajoutent progressivement des fonctionnalites 
au produit. 

Cycle de vie predictif / Predictive Life Cycle. Forme de cycle de vie d’un projet dans laquelle le perimetre, la duree et 
les couts du projet sont determines au cours des premieres phases du cycle de vie. 

Date de debut / Start Date. Moment associe au debut de I'activite de I'echeancier, generalement qualifie par I’un des 
termes suivants : reelle, prevue, estimee, planifiee, au plus tot, au plus tard, cible, de reference de base ou actuelle. 

Date de debut au plus tard / Late Start Date (LS). Dans la methode du chemin critique, derniere date possible a 
laquelle les parties inachevees d’une activite de I’echeancier doivent commences compte tenu de la logique du reseau, 
de la date d’achevement du projet et des contraintes sur I’echeancier. 

Date de debut au plus tot / Early Start Date (ES). Dans la methode du chemin critique, premiere date possible a 
laquelle les parties inachevees d’une activite de I'echeancier peuvent demarrer, compte tenu de la logique du reseau, 
de la date des donnees et des contraintes sur I’echeancier. 

Date de fin / Finish Date. Date a laquelle une activite de I'echeancier est achevee. Cette date est generalement 
completee par un qualificatif: reelle, planifiee, estimee, au plus tot, au plus tard, de reference de base, cible ou actuelle. 

Date de fin au plus tard / Late Finish Date (LF). Dans la methode du chemin critique, derniere date possible a laquelle 
les parties inachevees d’une activite de I’echeancier doivent etre terminees, compte tenu de la logique du reseau, de la 
date d’achevement du projet et des contraintes sur I’echeancier. 

Date de fin au plus tot / Early Finish Date (EF). Dans la methode du chemin critique, premiere date possible a laquelle 
les parties inachevees d’une activite de I’echeancier peuvent etre terminees, compte tenu de la logique du reseau, de la 
date des donnees et des contraintes sur I’echeancier. 

Date des donnees / Data Date. Enregistrement de I'avancement du projet a un moment donne. 

Date imposee / Imposed Date. Date imposee a une activite ou a un jalon de I'echeancier, generalement sous la forme 
« ne pas demarrer avant telle date»ou« ne pas finir plus tard que telle date». 

Decisions « Make-or-Buy »/ Make-or-Buy Decisions. Decisions concernant la realisation en interne (« Make ») ou 
I’acquisition en externe (« Buy») d’un produit, un resultat ou d’un service. 

Decomposition / Decomposition. Technique utilisee pour diviser et subdiviser le perimetre et les livrables du projet en 
elements plus petits et plus faciles a gerer. 

Defaut / Defect. Imperfection ou deficience d’un element du projet, qui entraine le non-respect des exigences ou des 
specifications correspondantes, et done, la necessity de le reparer ou de le remplacer. 
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Definir le perimetre / Define Scope. Processus qui consiste a developper une description detaillee du projet et du produit. 

Definir les activites / Define Activities. Processus qui consiste a identifier et a documenter les actions specifiques a 
effectuer pour produire les livrables du projet. 

Demande d’information (Request for Information, RFI) / Request for Information (RFI). Type de document 
d’approvisionnement dans lequel I’acheteur demande a un fournisseur potentiel de lui fournir diverses informations 
relatives a un produit, a un service, ou a certaines de ses capacites. 

Demande de changement / Change Request. Proposition formelle de modifier un document donne, un livrable ou une 
reference de base. 

Demande dedevis(Requestfor Quotation, RFQ)/RequestforQuotation(RFQ). Type dedocumentd’approvisionnement 
utilise pour solliciter des propositions de prix de la part de fournisseurs potentiels de produits ou de services courants 
ou standards. La demande de devis est parfois utilisee au lieu d’un appel d’offres. La signification de cette appellation 
peut etre plus restreinte ou plus specifique dans certains champs d’application. 

Dependance / Dependency. Voir lien logique. 

Dependance obligatoire / Mandatory Dependency. Lien logique qui est contractuellement exige ou inherent a la 
nature du travail. 

Dependance optionnelle / Discretionary Dependency. Categorie de lien logique base sur les meilleures pratiques 
dans un domaine d’application donne, ou pour un aspect du projet pour lequel une sequence specifique est souhaitee. 

Dependances externes / External Dependency. Liens entre des activites du projet et des activites hors projet. 

Derive du perimetre / Scope Creep. L’expansion non controlee du contenu du produit ou du perimetre du projet sans 
ajustements de la duree, du cout ou des ressources. 

Description du contenu du produit / Product Scope Description. Description narrative documentee du contenu 
du produit. 

Determiner le budget / Determine Budget. Processus qui consiste a cumuler les couts estimes de chaque activite ou 
de chaque lot de travail, de fagon a etablir une reference de base de performance des couts approuvee. 

Developper i’equipe / Develop Team. Processus qui consiste a ameliorer les competences des membres de I’equipe, 
leur cooperation, et I'environnement global de I’equipe, afin d’ameliorer la performance du projet. 

Diagramme cause-effet / Cause and Effect Diagram. Technique de decomposition qui contribue a mettre en relation 
un effet indesirable avec sa cause fondamentale. 

Diagramme de controie / Control Chart. Representation graphique des donnees d’un processus dans le temps, par 
rapport a des seuils de controie definis; il comporte une ligne centrale qui permet de detecter une tendance des valeurs 
reportees, vers I’un ou I’autre de ces seuils. 

Diagramme de flux / Flowchart. Presentation sous forme de diagramme des donnees d’entree, des actions du 
processus et des donnees de sortie d’un ou plusieurs processus faisant partie d’un systeme. 

Diagramme de Gantt / Gantt Chart. Graphique a barres des donnees de I’echeancier dans lequel les activites sont 
presentees sur I’axe des ordonnees, les dates sont indiquees sur I’axe des abscisses et les durees des activites sont 
representees sous forme de barres horizontales placees en fonction des dates de debut et de fin correspondantes. 

Diagramme de reseau du projet / Project Schedule Network Diagram. Representation graphique des liens logiques 
entre les activites de I’echeancier du projet. 
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Diagramme en arete de poisson / Fishbone diagram. Voir Diagramme cause-effet. 

Diagramme Tornado / Tornado Diagram. Type particular de graphique a barres, utilise dans le cadre d’une analyse 
de sensibilite, pour comparer I'importance relative des variables. 

Diagrammes d’affinite / Affinity Diagrams. Technique permettant de grouper des idees afin de les passer en revue 
et de les analyser. 

Diagrammes matriciels / Matrix Diagrams. Outil de martrise de la qualite utilise pour effectuer des analyses de 
donnees au sein de la structure organisationnelle creee dans la matrice. Le diagramme matriciel vise a montrer la force 
des relations entre les facteurs, causes et objectifs qui existent entre les lignes et les colonnes qui torment la matrice. 

Dictionnaire du WBS / WBS Dictionary. Document qui fournit des informations detaillees sur les livrables, I’activite et 
I’echeancier pour chaque element dans I’organigramme des travaux du projet. 

Diriger et gerer le travail du projet / Direct and Manage Project Work. Processus qui consiste a diriger et a realiser 
le travail defini dans le plan de management du projet et a appliquer les changements approuves pour atteindre les 
objectifs du projet. 

Divergence des chemins / Path Divergence. Relation dans laquelle une activite de I'echeancier a plus d’un successeur. 

Document devaluation et de test / Test and Evaluation Documents. Documents du projet qui decrivent les activites 
permettant de determiner si le produit est conforme aux objectifs relatifs a la qualite decrits dans le plan de gestion de 
la qualite. 

Documentation des exigences / Requirements Documentation. Decrit la fagon dont chacune des exigences satisfait 
les besoins des parties prenantes du projet. 

Documents d’appel d’offres / Bid Documents. Documents utilises pour solliciter des informations, des devis ou des 
propositions de la part de fournisseurs potentiels. 

Documents d’approvisionnement / Procurement Documents. Documents utilises dans les activites relatives aux 
offres et aux propositions, qui comprennent, pour I’acheteur, I’appel a soumissionner, I'appel a la negociation, la 
demande d'information, la demande de devis, I'appel d’offres et les reponses des fournisseurs. 

Documents d’approvisionnement / Procurement Documentation. Tous les documents qui permettent de signer, 
d’executer et de conclure un accord. II peuts’agir de documents anterieurs au projet. 

Domaine de connaissance en management de projet / Project Management Knowledge Area. Domaine identifie 
du management de projet, defini par ses exigences en matiere de connaissance et dont le contenu est decrit en termes 
de ses processus, ses pratiques, ses donnees d’entree et de sortie, ses outils et techniques. 

Donnee d’entree / Input. Tout element, interne ou externe au projet, qui s'avere necessaire au demarrage d’un 
processus. Cette donnee d’entree peut correspondre a une donnee de sortie d’un processus precedent. 

Donnee de sortie / Output. Produit, resultat ou service genere par un processus. Cette donnee de sortie peut etre une 
donnee d’entree pour un ou plusieurs autres processus successeurs eventuels. 

Donnees / Data. Observations brutes ou mesures discretes, non traitees et non organisees. 

Donnees de I’echeancier / Schedule Data. Ensemble des informations utilisees pour decrire et maTtriser I'echeancier. 

Donnees de performance d’execution / Work Performance Data. Observations brutes et mesures relevees au cours 
de I'execution des activites pour realiser le travail du projet. 


707 



Donnees historiques / Historical Information. Documents et donnees des projets anterieurs, comprenant fichiers, 
dossiers, correspondence, contrats et projets clos. 

Duree / Duration. Nombre total de periodes de travail necessaires a la finalisation d’une activite ou d’un element de 
I'organigramme des travaux du projet, qui est exprime en heures, en jours ou en semaines. Nepas confondre avec Effort. 

Duree de I’activite / Activity Duration. Duree exprimee en unites calendaires entre le debut et la fin d’une activite de 
I'echeancier. Voir aussi Duree. 

Duree reelle / Actual Duration. Duree en unites calendaires entre la date de debut reelle de I’activite de I’echeancier et, soit 
la date des donnees de I’echeancier du projet (si cette activite est en cours), soit la date de fin reelle (si elle est terminee). 

Ecart / Variance. Deviation, derive ou divergence quantifiable par rapport a une reference de base connue ou a une 
valeur prevue. 

Ecart a terminaison (Variance at Completion, VAC) / Variance At Completion (VAC). Projection du montant du deficit 
ou de I’excedent budgetaire, exprime comme la difference entre le budget a terminaison et le cout estime a terminaison. 

Ecart de cout (Cost Variance, CV) / Cost Variance (CV). Le montant du deficit ou de I’excedent budgetaire a un point 
donne dans le temps, exprime comme la difference entre la valeur acquise et le cout reel. 

Ecart de delais (Schedule Variance, SV) / Schedule Variance (SV). Mesure d’avancement de I'echeancier exprimee 
comme la difference entre la valeur acquise et la valeur planifiee. 

Echantillonnage par attributs / Attribute Sampling. Methode de mesure de la qualite qui consiste a relever la 
presence (ou I’absence) d’une caracteristique ou d’un attribut donne au niveau de chacune des unites a I’etude. 

Echantillonnage statistique / Statistical Sampling. Choix d’une partie de la population visee pour examen. 

Echeancier / Schedule. Voir Echeancier du projet et Modele d’echeancier. 

Echeancier a jalons / Milestone Schedule. Echeancier recapitulate dans lequel figurent les principaux jalons. Voir 
aussi Echeancier directeur. 

Echeancier directeur / Master Schedule. Echeancier recapitulate du projet dans lequel sont identifies les principaux 
livrables et elements de I’organigramme des travaux du projet, ainsi que les jalons cles de I’echeancier. Voir aussi 
Echeancier a jalons. 

Echeancier du projet / Project Schedule. Une donnee de sortie d’un modele d’echeancier qui presente des activites 
liees avec des dates planifiees, des durees, des jalons et des ressources. 

Effectuer I’analyse qualitative des risques / Perform Qualitative Risk Analysis. Processus qui consiste a hierarchiser 
les risques individuels du projet afin de les analyser ou de les exploiter ulterieurement en evaluant leur probabilite 
d’occurrence ou leur impact parmi d’autres caracteristiques. 

Effectuer I’analyse quantitative des risques / Perform Quantitative Risk Analysis. Processus qui consiste a 
analyser de fagon mesurable les effets des risques individuels du projet identifies et des autres sources d’incertitudes 
sur I'ensemble des objectifs du projet. 

Effort / Effort. Nombre d’unites de travail necessaires a la finalisation d’une activite de I’echeancier ou d’un element 
de I'organigramme des travaux du projet, souvent exprimees en heures, en jours ou en semaines. Ne pas confondre 
avec Duree. 
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Effort unitaire / Discrete Effort. Activite susceptible d'etre planifiee et mesuree qui permet d’obtenir des donnees de 
sortie specifiques. (Remarque : I’effort unitaire est I’un des trois types de gestion de la valeur acquise des activites qui 
visent a mesurer la performance d’execution.) 

Elaboration progressive / Progressive Elaboration. Processus iteratif qui consiste a augmenter le niveau de detail 
dans un plan de management du projet au fur et a mesure que de plus amples informations et des estimations plus 
precises deviennent disponibles. 

Elaborer I’echeancier / Develop Schedule. Processus qui consiste a elaborer le modele d'echeancier du projet a partir 
de I’analyse des sequences d’activites, des durees, des besoins en ressources et des contraintes de I’echeancier a des 
fins d’execution et de martrise du projet. 

Elaborer la charte du projet / Develop Project Charter. Processus consistant a developper un document qui autorise 
formellement I'existence d’un projet et donne autorite au chef de projet pour affecter des ressources de I'organisation 
aux activites de ce projet. 

Elaborer le plan de management du projet / Develop Project Management Plan. Processus qui consiste a definir, a 
preparer et a coordonner tous les elements de plan et a les consolider dans un plan de management du projet integre. 

Element de I’organigramme des travaux du projet / Work Breakdown Structure Component. Element de 
I’organigramme des travaux du projet pouvant se trouver a n'importe quel niveau de cette structure. 

Enonce des travaux (Statement of Work, SOW) / Statement of Work (SOW). Description narrative des produits, des 
services ou des resultats a fournir par le projet. 

Enonce des travaux d’approvisionnement / Procurement Statement of Work. II fournit une description suffisamment 
detaillee du sujet de I'approvisionnement pour permettre aux fournisseurs potentiels de determiner s’ils sont capables 
de fournir les produits, les services ou les resultats. 

Enonce du perimetre du projet / Project Scope Statement. Description du perimetre du projet, des principaux 
livrables, des hypotheses et des contraintes. 

Entretiens / Interviews. Approche formelle ou informelle permettant, par un dialogue direct avec les parties prenantes, 
de collecter des informations. 

Equipe de management de projet / Project Management Team. Membres de l equipe projet directement impliques 
dans les activites de management de projet. Voir aussi Equipe projet. 

Equipe projet / Project Team. Un ensemble d'individus qui apportent leur soutien au chef de projet pour I’execution des 
travaux du projet en vue d'en atteindre les objectifs. Voir aussi Equipe de management de projet. 

Equipes auto-organisees / Self-Organizing Teams. Formation au sein de laquelle I’equipe fonctionne sans 
coordination centralist. 

Equipes virtuelles / Virtual Teams. Groupes dont les membres ont un objectif commun et remplissent leur role sans 
jamais se rencontrer en personne ou tres peu. 

Escalade des risques / Risk Escalation. Strategie de reponse aux risques par laquelle I’equipe reconnaft I’existence 
d’un risque en dehors de sa sphere d'influence et en transfere la responsabilite a un echelon superieur de I’organisation 
ou il sera gere de maniere plus efficace. 

Estimation / Estimate. Evaluation quantitative du resultat probable d’une variable, comme les durees, les efforts, les 
ressources ou les couts d’un projet. 
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Estimation a trois points / Three-Point Estimating. Technique utilisee pour I’estimation du cout ou de la duree en 
appliquant une moyenne ou une moyenne ponderee des estimations optimiste, pessimiste et plus probable, lorsqu’une 
incertitude pese sur les estimations des activites individuelles. 

Estimation ascendante / Bottom-Up Estimating. Methode d'estimation de la duree ou du cout du projet en cumulant 
les estimations de cout des elements des niveaux inferieurs de I'organigramme des travaux du projet (WBS). 

Estimation par analogic / Analogous Estimating. Technique d’estimation de la duree ou du cout d’une activity ou d’un 
projet en utilisant des donnees historiques d’une activite ou d’un projet similaire. 

Estimation parametrique / Parametric Estimating. Technique d’estimation dans laquelle un algorithme est utilise 
pour calculer le cout ou la duree en se basant sur des donnees historiques et des parametres du projet. 

Estimations de la duree d’une activite / Activity Duration Estimates. Evaluations quantitatives du nombre probable 
de periodes de temps requis pour realiser une activite. 

Estimations independantes / Independent Estimates. Processus qui consiste a faire appel a un tiers pour obtenir et 
analyser les informations visant a appuyer des previsions de cout, d'echeancier ou d’autres elements. 

Estimer la duree des activites / Estimate Activity Durations. Processus qui consiste a estimer le nombre de periodes 
de travail requises pour achever les activites individuelles avec les ressources estimees. 

Estimer les couts / Estimate Costs. Processus qui consiste a estimer les ressources monetaires necessaires a la 
realisation des travaux du projet. 

Estimer les ressources necessaires aux activites / Estimate Activity Resources. Processus qui consiste a evaluer les 
ressources d’une equipe mais aussi le type et les quantites du materiel, de I’equipement et des fournitures necessaires 
a la realisation des travaux du projet. 

Evaluation de la qualite des donnees relatives aux risques / Risk Data Quality Assessment. Technique permettant 
d’evaluer dans quelle mesure les donnees sur les risques sont utiles pour la gestion des risques. 

Evaluation des risques / Risk Enhancement. Strategic de reponse aux risques par laquelle I'equipe projet agit pour 
augmenter la probability d’occurrence ou I’impact d’une opportunity. 

Evaluation des styles de communication / Communication Styles Assessment. Technique permettant d'identifier 
le mode de communication privilegie des parties prenantes, sa forme et son contenu dans le cadre d’activites de 
communication planifiees. 

Evitement du risque / Risk Avoidance. Strategie de reponse aux risques destinee a eliminer la menace ou proteger 
le projet de son impact. 

Exactitude / Accuracy. Une evaluation de la justesse d’une mesure au sein du systeme de gestion de la qualite. 

Executer / Execute. Diriger, gerer, effectuer et realiser le travail du projet; fournir les livrables; fournir les informations 
sur la performance d’execution. 

Executer les reponses aux risques / Implement Risk Responses. Processus qui consiste a mettre en oeuvre les plans 
de reponse aux risques convenus. 

Exigence / Requirement. Condition ou capacity qui doit etre presente dans un produit, un service ou un resultat, pour 
satisfaire a un besoin. 

Exigence de qualite / Quality Requirement. Une condition ou une capacity qui sera utilisee pour evaluer la conformity, 
en validant I’acceptabilite d’un attribut comme indicateur de la qualite d’un resultat. 
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Exploitation des risques / Risk Exploiting. Strategie de reponse aux risques par laquelle I'equipe projet agit pour 
garantir une opportunite. 

Exposition aux risques / Risk Exposure. Mesure totale de I’impact potentiel de tous les risques a un moment donne 
d’un projet, d’un programme ou d’un portefeuille, 

Facteurs environnementaux de (’organisation / Enterprise Environmental Factors. Parametres qui ne sont pas sous 
le controle immediat de I'equipe et qui influencent, contraignent ou orientent le projet, le programme ou le portefeuille. 

Fiches de controle / Checksheets. Une fiche de rapprochement et de comptage qui peut etre utilisee comme liste de 
controle lors de la collecte des donnees. 

Fournisseur / Seller. Prestataire ou fournisseur de produits, de services ou de resultats a une organisation. 

Gerer (’engagement des parties prenantes / Manage Stakeholder Engagement. Processus qui consiste a 
communiquer et a travailler avec les parties prenantes afin de satisfaire a leurs besoins et a leurs attentes, de resoudre 
les points a traiter et de les encourager a participer de maniere adequate. 

Gerer I’equipe / Manage Team. Processus qui consiste a suivre la performance des membres de I’equipe, a fournir 
des retours d'information, a resoudre des points a traiter et a gerer des changements d’equipe en vue d’optimiser la 
performance du projet. 

Gerer la qualite / Manage Quality. Processus qui consiste a transformer le plan de gestion de la qualite en activites 
realisables dans ce domaine tout en integrant au projet les politiques qualite de I'organisation. 

Gerer les communications / Manage Communications. Processus qui consiste a assurer, de maniere appropriee et 
en temps utile, la collecte, la creation, la distribution, la conservation, la recherche, la gestion, la maTtrise et I’archivage 
final des informations du projet. 

Gerer les connaissances du projet / Manage Project Knowledge. Processus qui consiste a utiliser les connaissances 
existantes et a acquerir de nouvelles competences pour atteindre les objectifs du projet et contribuer a I’apprentissage 
organisationnel. 

Gestion de I’echeancier du projet / Project Schedule Management. Processus permettant de gerer I'achevement 
du projet dans les delais impartis. 

Gestion de (’integration du projet / Project Integration Management. Les processus et les activites qui identifient, 
definissent, combinent, unifient et coordonnent les differents processus et activites de management de projet au sein 
des groupes de processus de management du projet. 

Gestion de la qualite du projet / Project Quality Management. Processus de prise en compte de la politique qualite 
de I'organisation en ce qui concerne la planification, la gestion et la maTtrise des exigences de qualite du produit et du 
projet afin de satisfaire aux attentes des parties prenantes. 

Gestion de la valeur acquise / Earned Value Management. Methode qui integre le perimetre, le delai et les mesures 
de performance des ressources pour evaluer la performance et I'avancement du projet. 

Gestion des approvisionnements du projet / Project Procurement Management. La gestion des approvisionnements 
du projet comprend les processus d’achat ou d’acquisition des produits, des services ou des resultats necessaires et 
externes a I’equipe projet. 

Gestion des communications du projet / Project Communications Management. Processus requis pour assurer, 
de maniere appropriee et en temps utile, la planification, le recueil, la creation, la distribution, la conservation, 
la recuperation, la gestion, la maTtrise et I’archivage final des informations du projet. 
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Gestion des couts du projet / Project Cost Management. Processus relatifs a la planification, a I’estimation, a 
I'etablissement du budget, au financement, au provisionnement, a la gestion et a la martrise des couts, afin que le projet 
soit acheve dans les limites du budget approuve. 

Gestion des parties prenantes du projet / Project Stakeholder Management. Processus requis pour identifier les 
personnes, les groupes ou les organisations susceptibles d’affecter ou d’etre affectes par le projet, pour analyser les 
attentes des parties prenantes et leur impact sur le projet, mais aussi pour developper des strategies de gestion appropriees 
afin de mobiliser efficacement les parties prenantes en les impliquant dans les decisions du projet et son execution. 

Gestion des reclamations / Claims Administration. Le processus de traitement, devaluation et de communication 
des reclamations et des revendications contractuelles. 

Gestion des ressources du projet / Project Resource Management. Processus qui consiste a identifier, a obtenir et 
a gerer les ressources requises pour garantir I'achevement du projet. 

Gestion des risques du projet / Project Risk Management. Processus de planification de la gestion des risques, 
d’identification, d’analyse, de planification des reponses, d’application d’une reponse et de martrise des risques d’un projet. 

Gestion du perimetre du projet / Project Scope Management. Processus permettant d’assurer que tout le travail 
requis par le projet, et seulement le travail requis, est effectue pour mener le projet a son terme avec succes. 

Gestionnaire des ressources / Resource Manager. Personne disposant de I’autorite managerial sur une ou 
plusieurs ressources. 

Gouvernance du projet / Project Governance. Cadre, fonctions et processus qui guident les activites de management 
de projet afin de developper un service, un produit ou un resultat unique permettant d’atteindre des objectifs 
organisationnels, strategies et operationnels. 

Graphique a barres / Bar Chart. Representation graphique des informations de I'echeancier. Dans un graphique a 
barres classique, la liste des activites de I’echeancier, ou les elements de I’organigramme des travaux du projet, se 
trouvent sur I’axe des ordonnees du diagramme, les dates sont indiquees sur I'axe des abscisses, et les activites sont 
representees par des barres horizontales de dimension proportionnelle a leur duree. Voir aussi diagramme de Gantt. 

Graphique d’influence / Influence Diagram. Representation graphique de situations, qui montre les relations de 
causalite, la chronologie des evenements et d’autres relations entre les variables et les resultats. 

Groupe de processus d’execution / Executing Process Group. Processus permettant de realiser le travail defini dans 
le plan de management du projet afin de satisfaire aux exigences du projet. 

Groupe de processus d’initialisation / Initiating Process Group. Ces processus permettent de definir un nouveau 
projet, ou une nouvelle phase d’un projet existant, par I’obtention de I’autorisation de demarrer ce nouveau projet ou 
cette nouvelle phase. 

Groupe de processus de cloture / Closing Process Group. Processus permettant de realiser ou de clore formellement 
un projet, une phase ou un contrat. 

Groupe de processus de martrise / Monitoring and Controlling Process Group. Ces processus permettent de suivre, 
de passer en revue et de reguler I’avancement et la performance du projet, d’identifier les endroits ou des changements 
du plan s'avereraient necessaires, et d’entreprendre les changements correspondents. 

Groupe de processus de management de projet / Project Management Process Group. Groupement logique des 
donnees d’entree, des outils et techniques, et des donnees de sortie du management de projet. Les groupes de processus 
de management de projet comprennent les processus d’initialisation, de planification, d’execution, de maitrise, et enfin 
de cloture. Les groupes de processus de management du projet ne sont pas des phases du projet. 
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Groupe de processus de planification / Planning Process Group. Ces processus permettent d’elaborer le perimetre 
du projet, d’affiner les objectifs et de definir la suite des actions necessaires a I’atteinte des objectifs pour lesquels le 
projet a ete entrepris. 

Groupes de discussion / Focus Groups. Technique de collecte de donnees qui rassemble des parties prenantes 
preselectionnees et des experts sur le sujet, dans le but de savoir quelles sont leurs attentes et leurs attitudes sur un 
produit, un service ou un resultat propose. 

Histogramme / Histogram. Graphique a barres fournissant une representation graphique des donnees numeriques. 

Histogramme des ressources / Resource Histogram. Graphique a barres verticales representant pour un intervalle 
de temps donne la charge de travail totale assignee a une ressource specifique. 

Hypothese / Assumption. Une hypothese est un facteur qui, dans le processus de planification, est considere comme 
vrai, reel ou certain, sans preuve ni demonstration. 

Identifier les parties prenantes / Identify Stakeholders. Processus qui consiste a identifier regulierement les parties 
prenantes du projet mais aussi a analyser et a documenter des informations pertinentes concernant leurs interets, leur 
participation, leurs interdependences, leur influence et leur impact potentiel sur la reussite du projet. 

Identifier les risques / Identify Risks. Processus qui consiste a identifier les risques individuels et les sources du 
risque global ainsi qu’a en documenter les caracteristiques. 

Indice de performance a terminaison du projet (To-Complete Performance Index, TCPI) / To-Compiete 
Performance Index (TCPI). Mesure de la performance des couts qui doit etre atteinte avec les ressources restantes 
afin de satisfaire a un objectif de management donne, exprimee par le ratio du cout pour terminer le travail non acheve 
par rapport au budget restant. 

Indice de performance des couts (Cost Performance Index, CPI) / Cost Performance Index (CPI). Une mesure de 
rendement du cout des ressources budgetisees exprimee par le ratio de la valeur acquise rapportee au cout reel. 

Indice de performance des delais (Schedule Performance Index, SPI) / Schedule Performance Index (SPI). Mesure 
de rendement de I’echeancier exprimee par le ratio de la valeur acquise rapportee a la valeur planifiee. 

Information sur la performance d’execution / Work Performance Information. Donnees de performance recueillies 
a travers les divers processus de maTtrise qui sont analysees par rapport aux elements du plan de management du 
projet, des documents du projet et autres. 

Informations / Information. Donnees structures ou organisees, traitees a une fin specifique, afin de les rendre 
significatives, precieuses et utiles dans des contextes precis. 

Initialisation du projet / Project Initiation. Lancementd’un processus qui peut aboutir a I’autorisation d’un nouveau projet. 

Inspection / Inspection. Etude du produit d’un travail afin de determiner sa conformite aux standards documents. 

Intelligence emotionnelle / Emotional Intelligence. Capacite a identifier, a evaluer et a gerer ses emotions personnels 
et celles d’autres personnes, au meme titre que les emotions collectives de groupes de personnes. 

Jalon / Milestone. Point ou evenement significatif d'un projet, d’un programme ou d’un portefeuille. 

Journal / Log. Document utilise pour enregistrer, decrire ou annoter des elements specifiques identifies au cours de 
I'execution d’un processus ou d’une activite. Generalement complete par un determinant, tel que journal des points a 
traiter, des changements ou des hypotheses. 

Journal des changements / Change Log. Liste complete des changements apportes au cours du projet avec leur 
etat actuel. 
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Journal des hypotheses / Assumption Log. Document de projet utilise tout au long du cycle de vie du projet pour 
consigner toutes les hypotheses et les contraintes. 

Journal des points a traiter / Issue Log. Document de projet dans lequel les informations sur les points a traiter sont 
consignees et maitrisees. 

Jugement a dire d’expert / Expert Judgment. Jugement emis en vertu d’une expertise dans un champ d’application, 
un domaine de connaissance, une discipline, un secteur d’activite, etc., cette expertise s'averant appropriee quant a 
I’activite effectuee. Une telle expertise peut etre fournie par un groupe ou une personne ayant suivi des etudes adequates 
et possedant une connaissance, une competence, une experience ou une formation professionnelle specialist. 

Liaison debut-debut (DD) / Start-to-Start (SS). Relation logique dans laquelle une activite successeur ne peut pas 
commencer avant qu’une activite predecesseur n'ait commence. 

Liaison debut-tin (DF) / Start-to-Finish (SF). Relation logique dans laquelle une activite successeur ne peut pas se 
terminer avant qu’une activite predecesseur n'ait commence. 

Liaison tin-debut (FD) / Finish-to-Start (FS). Relation logique dans laquelle une activite successeur ne peut pas 
commencer tant qu’une activite predecesseur n’est pas achevee. 

Liaison tin-tin (FF) / Finish-to-Finish (FF). Relation logique dans laquelle une activite successeur ne peut pas se 
terminer tant qu’une activite predecesseur n’est pas achevee. 

Lien logique / Logical Relationship. Dependance entre deux activites ou entre une activite et un jalon. 

Limites de specifications / Specification Limits. Zone situee de part et d’autre de la ligne centrale (la moyenne) des 
donnees tracees sur un diagramme de controle, qui delimite les exigences du client pour un produit ou un service. Cette 
zone peut etre superieure ou inferieure a celle definie par les seuils de controle. Voir aussi Seuils de controle. 

Lissage des ressources / Resource Smoothing. Technique d’optimisation des ressources utilisant les marges libre et 
totale sans influer sur le chemin critique. Voir aussi Nivellementdes ressources et Techniques d’optimisation des ressources. 

Liste d’activites / Activity List. Tableau documents des activites de I'echeancier, contenant la description de chaque 
activite, son identifiant et une presentation suffisamment detaillee du perimetre du travail afin que les membres de 
I’equipe projet comprennent le travail a effectuer. 

Livrable / Deliverable. Tout type de produit, de resultat ou de capacite de realiser un service, de caractere unique et 
verifiable, qui est produit pourachever un processus, une phase ou un projet. 

Livrables acceptes / Accepted Deliverables. Produits, resultats ou capacites, generes par un projet et valides par le 
client du projet ou les commanditaires, comme repondant a leurs criteres d'acceptation specifies. 

Livrables verifies / Verified Deliverables. Livrables termines du projet qui ont ete verifies et confirmes pour en assurer 
I’exactitude, par le processus MaTtriser la qualite. 

Logique du reseau / Network Logic. Toutes les dependances entre les activites presentees dans un diagramme de 
reseau de I’echeancier du projet. 

Lot de planification / Planning Package. Element de I’organigramme des travaux du projet a un niveau inferieur a 
celui du Centre de Consolidation, dont le contenu du travail est connu, mais sans le detail des activites de I’echeancier. 
Voir aussi Centre de Consolidation. 

Lot de travaux / Work Package. Travail defini au plus bas niveau de I’organigramme des travaux du projet pour lequel 
le cout et la duree sont estimes et geres. 
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MaTtrise / Control. Comparer les performances reelles aux performances prevues, analyser les ecarts, evaluer les 
tendances dans le but d’ameliorer les processus, evaluer les alternatives possibles et, au besoin, recommander des 
actions correctives appropriees. 

Maitrise des changements / Change Control. Processus par lequel les modifications apportees aux documents, aux 
livrables ou aux references de base associes au projet sont identifiees, documentees, approuvees ou rejetees. 

Maltriser I’echeancier / Control Schedule. Processus qui consiste a mettre a jour I’echeancier et a integrer les 
changements affectant la reference de base de I’echeancier. 

Maitriser I’engagement des parties prenantes / Monitor Stakeholder Engagement. Processus qui consiste 
a maitriser les relations avec les parties prenantes du projet et a adapter les strategies et les plans afin d’encourager 
leur engagement. 

Maltriser la qualite / Control Quality. Processus qui consiste a maltriser et enregistrer les resultats des activites de 
gestion de la qualite pour evaluer la performance et s'assurer de I'exhaustivite des donnees de sortie du projet, de leur 
exactitude et de leur capacite a satisfaire aux attentes des clients. 

Maitriser le perimetre et le contenu / Control Scope. Processus qui consiste a maitriser I’avancement du projet, 
verifier le contenu du produit et a integrer les changements affectant la reference de base du perimetre et du contenu. 

Maltriser le travail du projet / Monitor and Control Project Work. Processus qui consiste a suivre, passer en revue 
et communiquer les progres generaux pour atteindre les objectifs de performance definis dans le plan de management 
du projet. 

Maitriser les approvisionnements / Control Procurements. Processus qui consiste a gerer les relations fournisseurs, a 
suivre la performance, a effectuer les changements et corrections appropriees, le cas echeant, et a conclure des contrats. 

Maitriser les changements / Perform Integrated Change Control. Processus qui consiste a passer en revue toutes 
les demandes de changement, a approuver les changements, a gerer les changements apportes aux livrables, aux actifs 
organisationnels, aux documents du projet et au plan de management du projet ainsi qu’a communiquer les decisions. 

Maitriser les communications / Monitor Communications. Processus qui consiste a satisfaire les besoins en 
information du projet et de ses parties prenantes. 

Maitriser les couts / Control Costs. Processus qui consiste a mettre a jour les couts et a integrer les changements 
affectant la reference de base des couts. 

Maitriser les ressources / Control Resources. Processus qui consiste a s’assurer de la disponibilite des ressources 
affectees au projet, conformement aux previsions, a en maitriser I’utilisation reelle par rapport aux planifications et a 
effectuer des actions correctives, le cas echeant. 

Maitriser les risques / Monitor Risks. Processus qui consiste a maitriser la mise en oeuvre des plans de reponse aux 
risques convenus, a faire le suivi des risques identifies, a identifier de nouveaux risques, a les analyser et a evaluer 
I’efficacite du processus de gestion des risques tout au long du projet. 

Management de portefeuille / Portfolio Management. Le management centralise d’un ou de plusieurs portefeuilles 
afin d’atteindre des objectifs strategies. 

Management de programme / Program Management. Utilisation de connaissances, de competences et de principes 
necessaires a atteindre les objectifs d’un programme et ainsi d’obtenir des benefices et une maitrise qui vont au-dela 
d’une gestion individuelle des composants du programme. 
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Management de projet / Project Management. Application de connaissances, de competences, d’outils et de 
techniques aux activites du projet afin d’en respecter les exigences. 

Marge / Float. Synonyme de battement. Voir Marge totale et Marge libre. 

Marge libre / Free Float. Temps maximum dont une activite de I'echeancier peut etre retardee sans retarder la date de 
debut au plus tot de toute tache successeur ni enfreindre une contrainte de I'echeancier. 

Marge totale / Total Float. Temps maximum dont une activite de I'echeancier peut etre retardee ou etendue, par rapport 
a sa date de debut au plus tot, sans retarder la date de fin du projet ni transgresser une contrainte de I'echeancier. 

Matrice devaluation de I’engagement des parties prenantes / Stakeholder Engagement Assessment Matrix. 

Matrice qui compare les niveaux d’engagement actuel et souhaite des parties prenantes. 

Matrice de probabilite et d’impact / Probability and Impact Matrix. Grille de representation graphique de la 
probabilite d’occurrence de chaque risque et de son impact sur les objectifs du projet si ce risque se materialise. 

Matrice de tragabilite des exigences / Requirements Traceability Matrix. Tableau qui associe les exigences du 
produit depuis leur origine jusqu'aux livrables correspondants. 

Matrice des responsabilites (Responsibility Assignment Matrix, RAM) / Responsibility Assignment Matrix (RAM). 

Une matrice des ressources du projet affectees a chaque lot de travail. 

Matrice RACI / RACI Chart. Un type repandu de matrice des responsabilites qui fait appel aux postes Responsible 
[Realise], Accountable [Rend des comptes], Consult [Consulte] et Inform [Informe] pour definir la participation des 
parties prenantes aux activites du projet. 

Menace / Threat. Un risque qui aurait un impact negatif sur un ou plusieurs objectifs du projet. 

Mesures de controle de la qualite / Quality Control Measurements. Resultats documentes des activites de maTtrise 
de la qualite. 

Methode des antecedents (Precedence Diagramming Method, PDM) / Precedence Diagramming Method (PDM). 

Technique utilisee pour la construction d’un modele d’echeancier dans lequel les activites sont representees par des 
noeuds et sont graphiquement liees par un ou plusieurs liens logiques pour montrer I’ordre dans lequel les activites sont 
appelees a etre effectuees. 

Methode du chemin critique / Critical Path Method (CPM). Methode utilisee pour estimer la duree minimum du 
projet et determiner le degre de flexibility de I'echeancier sur les chemins de reseau logiques dans le cadre du modele 
de I'echeancier. 

Methodes de communication / Communication Methods. Procedure, technique ou processus systematique utilise 
pour le transfert des informations entre les parties prenantes du projet. 

Methodologie / Methodology. Systeme de pratiques, de techniques, de procedures et de regies utilisees par les 
personnes travaillant dans une discipline. 

Metriques qualite / Quality Metrics. Description d’un projet ou d’un attribut du produit et de la fagon de le mesurer. 

Mindmapping / Mind-Mapping. Aussi appele carte heuristique. Technique utilisee pour consolider les idees emises 
lors de seances de brainstorming individuelles sur une carte unique de fagon a faire ressortir les points communs et les 
differences ainsi qu’a produire de nouvelles idees. 
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Mise a jour / Update. Modification d’un livrable, d’un element du plan de management du projet ou d’un document de 
projet qui n'est pas soumis a une procedure formelle de maitrise des changements. 

Mise en parallele / Fast Tracking. Technique de compression de I'echeancier qui prevoit que des activites, ou des 
phases, normalement executees en sequence, sont executees en parallele, tout au moins sur une partie de leur duree. 

Modele d’echeancier / Schedule Model. Representation du plan d’execution des activites du projet, comprenant les 
durees, les dependences et d'autres informations de planification, utilisee pour produire un echeancier du projet ainsi 
que d’autres elements de planification du temps. 

Modeles / Templates. Document partiellement rempli et d’un format predefini qui fournit une structure precise pour la 
collecte, I'organisation et la presentation d’informations et de donnees. 

Modeles de communication / Communication Models. Description, analogie ou schema utilise pour decrire le 
processus de communication du projet. 

Networking / Networking. Etablissement de liens et de relations avec d’autres personnes de la meme organisation ou 
d’autres organisations. 

Niveau d’effort (Level of Effort, LOE) / Level of Effort (LOE). Une activite qui ne produit pas de produitsfinaux definitifs 
et qui est mesuree par le passage du temps. 

Nivellement des ressources / Resource Leveling. Technique d’optimisation des ressources selon laquelle les revisions 
de I’echeancier du projet visent a optimiser I’affectation des ressources et sont susceptibles d’influer sur le chemin 
critique. Voir aussi Technique d’optimisation des ressources etLissage des ressources. 

Noeud / Node. Point de convergence des lignes de dependance sur un diagramme de reseau du projet. 

Objectif / Objective. Quelque chose vers lequel un travail devra etre oriente, une position strategique a atteindre, un but 
a realiser, un resultat a obtenir, un produit a fabriquer, ou un service a realiser. 

Obtenir les ressources / Acquire Resources. Processus qui consiste a recruter les membres d’une equipe ainsi qu’a 
obtenir les infrastructures, les equipements, le materiel, les fournitures ettoutes les autres ressources necessaires a la 
realisation des travaux du projet. 

Obtention / Acquisition. Obtention des ressources humaines et materielles necessaires pour effectuer les activites 
d’un projet. Cette operation implique un cout, mais pas toujours sur le plan financier. 

Opportunity / Opportunity. Risque qui aurait un impact positif sur un ou plusieurs objectifs du projet. 

Organigramme des ressources / Resource Breakdown Structure. Representation hierarchique des ressources par 
categorie et par type. 

Organigramme des risques (Risk Breakdown Structure, RBS) / Risk Breakdown Structure (RBS). Representation 
hierarchique des sources de risque. 

Organigramme des travaux du projet (Work Breakdown Structure, WBS) / Work Breakdown Structure (WBS). 

Decomposition hierarchique du perimetre total du projet, qui definit le travail que I’equipe projet doit realiser pour 
atteindre les objectifs du projet et produire les livrables requis. 

Organigramme du projet / Project Organization Chart. Document representant de maniere graphique les membres 
de I'equipe projet avec leurs relations hierarchiques pour un projet donne. 


717 



Organigramme fonctionnel / Organizational Breakdown Structure (OBS). Representation hierarchique de I ’organisation 
du projet qui illustre la relation entre les activites du projet et les unites organisationnelles qui vont effectuer ces activites. 

Organisation fonctionnelle / Functional Organization. Structure organisationnelle au sein de laquelle les membres 
du personnel sont regroupes par domaines de specialisation et le chef de projet est autorise a affecter du travail et des 
ressources dans une mesure limitee. 

Organisation matricielle / Matrix Organization. Structure organisationnelle dans laquelle le chef de projet et les 
responsables fonctionnels partagent la responsabilite de fixer les priorites, d’affecter les ressources et de diriger le 
travail des personnes affectees au projet. 

Organisation sponsor / Sponsoring Organization. Entite responsable de fournir le sponsor du projet et un instrument 
pour le financement du projet ou d’autres ressources du projet. 

Organiser les activites en sequence / Sequence Activities. Processus qui consiste a identifier et documenter les 
relations entre les activites du projet. 

Outil / Tool. Element tangible, tel qu’un modele ou un logiciel, utilise lors de I'execution d’une activite pour generer un 
produit ou un resultat. 

Outil de planitication / Scheduling Tool. Outil qui fournit des noms des elements d’echeancier, des definitions, des 
liens structurels et des formats qui prennent en charge I’application d’une methode de planitication. 

Outils de maitrise des changements / Change Control Tools. Outils manuels ou automatises pour faciliter les 
changements ou la gestion de la configuration. Les outils doivent pour le moins prendre en charge les activites du 
comite de maitrise des changements. 

Partage des risques / Risk Sharing. Strategie de reponse aux risques par laquelle I’equipe projet attribue la 
responsabilite d’une opportunity a un tiers qui est le mieux a meme de beneficier de ses avantages. 

Partie prenante / Stakeholder. Individu, groupe ou organisme qui peut affecter, etre affecte ou percevoir d'etre affecte 
par une decision, une activite ou le resultat d’un projet, d’un programme ou d’un portefeuille. 

Perimetre / Scope. Somme des produits, services et resultats a fournir sous forme de projet. Voir aussi Perimetre du 
projet et Contenu du produit. 

Perimetre du projet / Project Scope. C’est le travail qui doit etre realise pour livrer un produit, un service ou un resultat 
possedant les caracteristiques et les fonctions specifies. 

Phase / Phase. Voir Phase du projet. 

Phase du projet / Project Phase. Ensemble d’activites conjointes du projet qui aboutit a la finalisation d’un ou de 
plusieurs livrables. 

Plan d’engagement des parties prenantes / Stakeholder Engagement Plan. Element du plan de management du 
projet qui identifie les strategies et les actions requises pour encourager I'implication productive des parties prenantes 
dans la prise de decision et I’execution du projet ou du programme. 

Plan de gestion de i’echeancier / Schedule Management Plan. Element du plan de management du projet ou du 
programme qui etablit les criteres et les activites pour le developpement et la maitrise de I’echeancier. 

Plan de gestion de I’equipe / Team Management Plan. Element du plan de gestion des ressources qui decrit quand 
et comment les membres de I’equipe seront recrutes et le temps pendant lequel ils seront necessaires. 
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Plan de gestion de la communication / Communications Management Plan. Un element du plan de management 
du projet, du programme ou du portefeuille qui decrit comment, quand et par qui les informations sur le projet seront 
administrees et diffusees. 

Plan de gestion de la configuration / Configuration Management Plan. Element d un plan de management du projet 
qui decrit le processus d'identification des elements du projet et de leur prise en compte dans le cadre de la maitrise de 
la configuration mais aussi qui explique comment en consigner les changements et rediger des rapports en consequence. 

Plan de gestion de la qualite / Quality Management Plan. Element du plan de management du projet ou du programme 
qui decrit la maniere dont les directives, les procedures et les politiques applicables seront appliquees pour atteindre les 
objectifs relatifs a la qualite. 

Plan de gestion des approvisionnements / Procurement Management Plan. Un element du plan de management du 
projet ou du programme qui decrit comment une equipe projet procedera pour obtenir des biens et services provenant 
de I'exterieur de I’organisation realisatrice. 

Plan de gestion des benefices / Benefits Management Plan. Explication documentee des processus de generation, 
d’optimisation et de perennisation des benefices issus d’un projet ou d’un programme. 

Plan de gestion des changements / Change Management Plan. Element du plan de management du projet qui 
etablit le comite de maitrise des changements, documente le champ d’application de son autorite et decrit le processus 
d’application du systeme de martrise des changements. 

Plan de gestion des couts / Cost Management Plan. Un element d’un plan de management du projet ou du programme 
qui decrit comment les couts seront planifies, structures et martrises. 

Plan de gestion des exigences / Requirements Management Plan. Un element du plan de management du projet ou 
du programme qui decrit comment les exigences seront analysees, documentees et gerees. 

Plan de gestion des ressources / Resource Management Plan. Element d’un plan de management du projet qui 
decrit comment les ressources sont obtenues, affectees et maftrisees. 

Plan de gestion des risques / Risk Management Plan. Un element du plan de management du projet, du programme 
ou du portefeuille qui decrit comment les activites de gestion des risques seront structures et realisees. 

Plan de gestion du perimetre / Scope Management Plan. Element du plan de management du projet ou du programme 
qui explique comment le perimetre sera defini, developpe, maitrise et valide. 

Plan de management du projet / Project Management Plan. Document qui decrit comment le projet sera execute, 
maitrise et clos. 

Plan de repli / Fallback Plan. Ensemble d’actions et de taches alternatives qui sont a disposition au cas ou le plan 
principal devrait etre abandonne en raison de I’occurrence de points a traiter, de risques ou d'autres causes. 

Planification en vagues / Rolling Wave Planning. Technique de planification iterative selon laquelle les travaux a 
realiser a court terme sont planifies en detail, tandis que les travaux a plus long terme le sont a un niveau moins detaille. 

Planifier I’engagement des parties prenantes / Plan Stakeholder Engagement. Processus qui consiste a developper 
des approches pour impliquer les parties prenantes du projet, en fonction de leurs besoins, de leurs attentes, de leurs 
interets et de leur impact potentiel sur le projet. 

Planifier la gestion de I’echeancier / Plan Schedule Management. Processus qui consiste a etablir les politiques 
internes, les procedures et la documentation pour la planification, le developpement, la gestion, I'execution et la maitrise 
de I'echeancierdu projet. 
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Planifier la gestion de la qualite / Plan Quality Management. Processus qui consiste a identifier les exigences de 
qualite et les standards a respecter pour le projet et ses livrables, et a documenter la fagon dont le projet demontrera sa 
conformite aux exigences et aux standards de qualite appropries. 

Planifier la gestion des approvisionnements / Plan Procurement Management. Processus qui consiste a documenter 
les decisions d'approvisionnement du projet, a specifier les approches et a identifier les fournisseurs potentiels. 

Planifier la gestion des communications / Plan Communications Management. Processus qui consiste a developper 
une approche et un plan appropries pour les activites de communication du projet, conformement aux besoins en 
information de chaque partie prenante ou groupe, aux actifs organisationnels disponibles et aux besoins du projet. 

Planifier la gestion des couts / Plan Cost Management. Processus qui consiste a definir la maniere dont les couts du 
projet seront estimes, budgetises, geres et maitrises. 

Planifier la gestion des ressources / Plan Resource Management. Processus qui consiste a definir la methode 
d’estimation, d'obtention, de gestion et d’utilisation des ressources physiques et d’une equipe. 

Planifier la gestion des risques / Plan Risk Management. Processus qui consiste a definir comment conduire les 
activites de gestion des risques d’un projet. 

Planifier la gestion du perimetre et du contenu / Plan Scope Management. Processus qui consiste a creer un plan 
de gestion du perimetre et du contenu qui documente la maniere dont le contenu du produit et le perimetre du projet 
seront definis, valides et maitrises. 

Planifier les reponses aux risques / Plan Risk Responses. Processus qui consiste a developper des options, 
selectionner des strategies et convenir d'actions visant a gerer I’exposition au risque global du projet, mais aussi a 
traiter chaque risque individuel du projet. 

Pluralite / Plurality. Decision prise par la partie la plus importante du groupe, meme si la majorite n'est pas atteinte. 

Point a traiter / Issue. Condition ou situation realisee susceptible d’influer sur les objectifs du projet. 

Politique interne / Policy. Schema structure d'actions adoptees par une organisation de maniere a ce que la politique 
interne de I'organisation puisse etre expliquee comme un ensemble de principes de base qui regissent la conduite de 
I’organisation. 

Politique qualite / Quality Policy. Politique specifique au domaine de connaissance en gestion de la qualite du projet, 
qui dicte les principes fondamentaux qui doivent regir les actions de I'organisation dans le cadre de I’application du 
systeme de gestion de la qualite. 

Porte de phase / Phase Gate. Revue en fin de phase au cours de laquelle la decision est prise de passer a la phase 
suivante, de continuer en apportant des changements ou de mettre fin a un projet ou a un programme. 

Portefeuille / Portfolio. Projets, programmes, portefeuilles subsidiaires et operations geres en tant que groupe dans le 
but d’atteindre des objectifs strategies. 

Pourcentage d’avancement / Percent Complete. Estimation, exprimee en pourcentage, du travail effectue pour une 
activite ou un element de I'organigramme des travaux du projet. 

Pratique/Practice. Type specifique d’activite professionnelle ou de gestion qui contribue a I’execution d’un processus 
et qui peut faire appel a un ou plusieurs outils et techniques. 

Prevision / Forecast. Une estimation ou un pronostic de situations ou d'evenements a venir dans le deroulement du 
projet, a partir d’informations et de connaissances disponibles au moment ou les previsions sont effectuees. 
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Previsions de I’echeancier / Schedule Forecasts. Estimations ou pronostics de situations ou d’evenements a 
venir dans le deroulement du projet, faits a partir d’informations et de connaissances disponibles au moment ou 
I’echeancier est calcule. 

Prime d’interessement / Incentive Fee. Ensemble d’incitations financiers qui sont liees au cout, a I’echeancier ou 
a la performance technique du fournisseur. 

Proceder aux approvisionnements / Conduct Procurements. Processus qui consiste a obtenir les reponses des 
fournisseurs, a selectionner un fournisseur et a attribuer un contrat. 

Procedure / Procedure. Methode etablie visant a realiser une performance ou un resultat coherent. Procedure 
pouvant generalement etre decrite comme la sequence des etapes a suivre pour executer un processus. 

Processus / Process. Serie systematique d’activites destinee a produire un resultat final en transformant une ou 
plusieurs donnees d’entree en une ou plusieurs donnees de sortie. 

Produit / Product. Objet qui est produit, quantifiable, et pouvant aussi bien etre un produit final qu’un composant. 
Synonyme de « materiels» et« marchandises ». Voir aussi Livrable. 

Programme / Program. Projets, programmes subsidiaires et activites de programme apparentes dont le management 
est coordonne afin d’obtenir des benefices qui ne seraient pas possibles en les traitant isolement. 

Projet / Project. Entreprise temporaire initiee dans le but de fournir un produit, un service ou un resultat unique. 

Propositions des fournisseurs / Seller Proposals. Reponses formelles des soumissionnaires a un appel d’offres ou 
tout autre document specifiant le prix, les conditions de vente, et les specifications techniques ou fonctionnelles que le 
fournisseur fera pour I’organisation demandeuse qui, si elles sont acceptees, obligeraient celui-ci a executer I'accord 
en resultant. 

Prototypes / Prototypes. Methode permettant un retour d’information rapide par rapport aux exigences, en mettant 
a disposition un modele fonctionnel du produit souhaite avant sa realisation. 

Qualite / Quality. Le degre de conformite aux exigences presente par I'ensemble des caracteristiques inherentes. 

Questionnaires / Questionnaires. Ensembles de questions ecrites qui permettent un recueil rapide d’informations 
a partir des reponses d’un grand nombre d’individus. 

Rapport de qualite / Quality Report. Document de projet comprenant les problemes de gestion de la qualite, les 
actions correctives recommandees et un recapitulate des resultats des activites de martrise de la qualite qui peut 
egalement inclure des recommandations d’ameliorations des processus, des projets et des produits. 

Rapport sur les risques / Risk Report. Document de projet, redige progressivement tout au long des processus de 
gestion des risques du projet, qui recapitule les informations sur les risques individuels des projets et le niveau de risque 
global du projet. 

Rapports sur la performance d’execution / Work Performance Reports. Representation physique ou electronique 
des informations sur la performance d’execution rassemblees dans les documents du projet, destinees a generer des 
prises de decision, des actions ou une sensibilisation. 

Reclamation / Claim. Requete. demande ou affirmation d’un droit par un vendeur a I’encontre d’un acheteur (ou 
reciproquement), en vue d’une prise en compte, d’un dedommagement ou d’un reglement selon les termes du contrat, 
par exemple dans le cas d’un changement conteste. 
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Reconciliation des limites de financement / Funding Limit Reconciliation. Processus de comparaison des depenses 
planifiees des fonds du projet avec des limites eventuelles d’engagement de fonds pour le projet afin d'identifier les 
eventuels ecarts entre les limites de financement et les depenses planifiees. 

Recueillir les exigences / Collect Requirements. Processus visant a determiner, documenter et gerer les besoins et 
les exigences des parties prenantes dans le but de satisfaire aux objectifs du projet. 

Reference de base / Baseline. Version approuvee du produit d’un travail qui peut etre changee uniquement par des 
procedures formelles de maTtrise des changements et qui est utilisee comme reference pour comparaison avec les 
resultats effectifs. 

Reference de base de i’echeancier / Schedule Baseline. Version approuvee d’un modele d’echeancier qui peut etre 
changee par des procedures formelles de maTtrise des changements et qui est utilisee comme base de comparaison 
aux resultats reels. 

Reference de base de la performance (Performance Measurement Baseline, PMB) / Performance Measurement 
Baseline (PMB). References de base integrees du perimetre, de I'echeancier et des couts qui sont destinees a gerer, 
evaluer et maTtriser I’execution du projet. 

Reference de base des couts / Cost Baseline. Version approuvee du budget echelonne du projet, a I’exclusion de toute 
reserve pour imprevus, qui ne peut etre changee qu’a travers les procedures formelles de maTtrise des changements 
et qui est utilisee comme base de comparaison avec les resultats reels. 

Reference de base du perimetre / Scope Baseline. Version approuvee d’un enonce du perimetre, de I'organigramme 
des travaux du projet (work breakdown structure, WBS) et de son dictionnaire du WBS associe qui peut etre changee 
par des procedures formelles de maTtrise des changements et qui est utilisee comme base de comparaison aux 
resultats reels. 

Registre des parties prenantes / Stakeholder Register. Document du projet comprenant I’identification, revaluation 
et la classification des parties prenantes du projet. 

Registre des retours d’experience / Lessons Learned Register. Document de projet utilise pour consigner les 
connaissances acquises qui sera exploite dans le cadre du projet actuel et integre a I’archive des retours d’experience. 

Registre des risques / Risk Register. Document dans lequel les donnees de sortie des processus de gestion des 
risques sont consignees. 

Regimentations / Regulations. Exigences imposees par un organisme gouvernemental. Ces exigences peuvent definir 
les caracteristiques du produit, du processus ou du service — y compris les dispositions administratives applicables — 
dont la conformite est regie par I'Etat. 

Regies de base / Ground Rules. Definition du minimum acceptable comme comportement des membres de 
I'equipe projet. 

Relation d’anteriorite / Precedence Relationship. Dependance logique utilisee dans le cadre de la methode des 
antecedents. 

Repertoire de I’equipe projet / Project Team Directory. Liste documentee des membres de I’equipe projet, avec leurs 
roles dans le projet et les informations necessaires a la communication. 

Reprise / Rework. Action organisation pour corriger un composant defectueux ou non conforme afin de le rendre 
conforme aux exigences ou aux specifications. 
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Reseau / Network. Voir Diagramme de reseau du projet. 

Reserve / Reserve. Disposition incluse dans le plan de management du projet pour attenuer les risques ayant un impact 
sur les couts et/ou I’echeancier. Ceterme, parfois remplace par provision, estsouvent utilise avec un determinant (exemple: 
provision pour imprevus, provision pour aleas) pour preciser les types de risques qui sont censes etre attenues. 

Reserve pour alea / Contingency Reserve. Temps ou argent consacre aux risques identifies, dans la reference de base 
des couts ou de I'echeancier, qui sont accompagnes de strategies de reponse actives. 

Reserve pour imprevus / Management Reserve. Element du budget ou de I’echeancier du projet non compris dans la 
reference de base qui est reserve auxtravaux non prevus dans le perimetre du projet. 

Responsabilite / Responsibility. Charge qui peut etre deleguee dans le cadre d’un plan de management du projet de 
telle sorte que la ressource affectee a le devoir de remplir les exigences de la charge en question. 

Ressource / Resource. Membre d’une equipe ou element physique necessaire a la realisation du projet. 

Resultat / Result. Produit de I’execution des processus de management et des activites du projet. Les resultats 
comprennent les systemes integres, processus revises, organisation restructures, tests, personnel forme, etc., ainsi que 
les documents tels que regies internes, plans, etudes, procedures, specifications, rapports. Voir aussi Livrable. 

Retard / Lag. Duree de report d’une activite successeur par rapport a une activite predecesseur. 

Retours d’experience / Lessons Learned. Connaissances utiles acquises au cours d’un projet pour ameliorer les 
performances futures. 

Revue des risques / Risk Review. Reunion pour examiner et documenter I’efficacite des reponses aux risques dans la 
gestion du risque global du projet et des risques individuels du projet identifies. 

Revues de la documentation / Documentation Reviews. Processus permettant de constituer un corpus d’informations 
et de le passer en revue afin d’en determiner I’exactitude et I’exhaustivite. 

Revues de performance / Performance Reviews. Technique utilisee pour mesurer, comparer et analyser les 
performances reelles des travaux en cours sur le projet par rapport a la reference de base de la performance. 

Risque / Risk. Evenement ou condition possible dont la concretisation aurait un impact positif ou negatif sur un ou 
plusieurs objectifs du projet. 

Risque global du projet / Overall Project Risk. Effet de I’incertitude sur I’ensemble du projet, provenant de toutes les 
sources possibles, comme les risques individuels, qui represente I'exposition des parties prenantes aux implications des 
variations, positives ou negatives, des resultats du projet. 

Risque residuel / Residual Risk. Risque qui persiste apres I'application des strategies de reponse. 

Risque secondaire / Secondary Risk. Risque resultant directement de I'application d’une reponse a un risque. 

Role / Role. Fonction definie qu’un membre de I’equipe projet doit executer, telle qu'effectuer des tests, de I'archivage, 
de I’inspection ou du codage. 

Schemas contextuels / Context Diagrams. Une representation visuelle du contenu du produit qui montre un systeme 
d’organisation (processus, materiel, systeme informatique, etc.), et comment les individus et les autres systemes 
(acteurs intervenants) interagissent avec celui-ci. 

Seuil / Threshold. Valeur predetermine d’une variable de projet mesurable qui represente une limite necessitant la 
realisation d’une action si elle est atteinte. 
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Seuil de risque / Risk Threshold. Niveau d’exposition aux risques au-dela duquel les risques sont maTtrises et en 
dessous duquel ils peuvent etre acceptes. 

Seuils de controle / Control Limits. Zone comprenant trois ecarts-types de chaque cote de la ligne centrale (ou 
moyenne) d’une distribution normale de donnees, reportees sur un diagramme de controle et qui reflete la variation 
attendue des donnees. Voir aussi Limites de specification. 

Simulation / Simulation. Technique analytique qui modele I’effet combine des incertitudes pour evaluer leur impact 
potentiel sur les objectifs. 

Simulation de Monte-Carlo / Monte Carlo Simulation. Technique d’analyse qui reproduit de nombreuses fois un 
modele informatique, dont les valeurs des donnees d’entree sont choisies de maniere aleatoire pour chaque iteration 
pilotee par les donnees d’entree, y compris les branches et les distributions probabilistes. Les donnees de sortie sont 
generees afin de representer I’eventail des resultats possibles pour le projet. 

Specifications / Specification. Enonce precis des besoins a satisfaire et des caracteristiques essentielles requises. 

Sponsor / Sponsor. Une personne ou un groupe qui fournit ressources et soutien au projet, au programme ou au 
portefeuille de projets et qui en facilite la reussite. 

Standard / Standard. Document redige en fonction d’une autorite, d’un usage ou d’un consentement general afin de 
servir de modele ou d’exemple. 

Strategie d’approvisionnement / Procurement Strategy. Approche utilisee par I'acheteur pour determiner la methode 
de livraison du projet et le type de contrat(s) contraignant(s) a signer afin de garantir les resultats souhaites. 

Strategies de reponse conditionnelles / Contingent Response Strategies. Actions planifiees qui peuvent etre 
utilisees dans le cas ou un evenement declencheur se produirait. 

Suivre / Monitor. Partie de la maTtrise consistant a collecter les donnees de performance du projet, definir des mesures 
de performance, generer des rapports et diffuser les informations correspondantes. 

Systeme d’information de management du projet (Project Management Information System, PMIS) / Project 
Management Information System. Un systeme d’information constitue des outils et techniques utilises pour collecter, 
integrer et diffuser les donnees de sortie des processus de management de projet. 

Systeme de gestion de la configuration / Configuration Management System. Ensemble de procedures utilisees 
pourfaire le suivi des elements du projet mais aussi en maitriser les changements. 

Systeme de gestion de la qualite / Quality Management System. Cadre organisationnel dont la structure dicte la 
politique interne, les processus, les procedures et les ressources necessaires a la mise en oeuvre du plan de gestion de la 
qualite. Le plan type de gestion de la qualite doit etre compatible avec le systeme de gestion de la qualite de I’organisation. 

Systeme de maitrise des changements / Change Control System. Un ensemble de procedures qui decrit comment 
les changements, apportes aux livrables du projet et a la documentation, sont geres et maTtrises. 

Systeme de maTtrise des changements du contrat / Contract Change Control System. Systeme qui permet de 
collecter, de suivre, d’evaluer et de communiquer les changements apportes a un contrat. 

Systemes de gestion de (’information / Information Management Systems. Infrastructures, processus et procedures 
permettant de recueillir, d’enregistrer et de diffuser des informations physiques ou electroniques entre leurs createurs 
et leurs destinataires. 
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Systemes de management de projet / Project Management System. L’ensemble des processus, des outils, des 
techniques, des methodes, des ressources et des procedures de management d’un projet. 

Tampon / Buffer. Voir Provision pour alea. 

Technique / Technique. Procedure definie et systematique utilisee par une ressource humaine pour effectuer une activite 
de creation d’un produit ou d’un resultat, ou de fourniture d’un service, et qui peut faire appel a un ou plusieurs outils. 

Technique d’optimisation des ressources / Resource Optimization Technique. Technique selon laquelle les dates de 
debut et de fin d’une activite sont adaptees afin d’assurer I'equilibre entre la demande en ressources et leur disponibilite. 
Voir aussi Nivellement des ressources et Lissage des ressources. 

Technique du groupe nominal / Nominal Group Technique. Technique qui renforce celle du brainstorming par la 
conduite d’un vote destine a classer les idees les plus utiles. Ces idees sont ensuite soumises a de nouvelles sessions 
de brainstorming ou classees par ordre de priorite. 

Techniques analytiques / Analytical Techniques. Diverses techniques utilisees pour evaluer, analyser ou prevoir des 
resultats potentiels en fonction de variations possibles du projet ou de variables d’environnement et de leurs relations 
avec d’autres variables. 

Techniques d’analyse des donnees / Data Analysis Techniques. Techniques utilisees pour organiser, analyser et 
evaluer des donnees et des informations. 

Techniques devaluation des propositions / Proposal Evaluation Techniques. Processus de revue des propositions 
des fournisseurs afin de simplifier les decisions relatives a I'attribution des contrats. 

Techniques de collecte des donnees / Data Gathering Techniques. Techniques utilisees pour collecter des donnees 
et des informations aupres de diverses sources. 

Techniques de prise de decision / Decision-Making Techniques. Techniques utilisees pour definir une ligne d’action 
a partir de plusieurs alternatives. 

Techniques de representation des donnees / Data Representation Techniques. Representations graphiques ou 
autres methodes utilisees pour communiquer des donnees et des informations. 

Techniques de representation en graphique / Diagramming Techniques. Techniques de presentation d’informations 
montrant les liens logiques pour contribuer a une meilleure comprehension. 

Technologie de communication / Communication Technology. Outils, systemes, logiciel d’ordinateur specifiques, 
etc., utilises pour transferer des informations entre les parties prenantes du projet. 

Tolerance / Tolerance. Description quantifier de la variation acceptable pour une exigence de qualite. 

Transfert des risques / Risk Transference. Strategie de reponse aux risques par laquelle I’equipe projet deplace vers 
un tiers, I’impact d’une menace et la responsabilite de la reponse. 

Unanimite / Unanimity. Accord de tous les membres du groupe sur une ligne d’action unique. 

Valeur acquise (Earned Value, EV) / Earned Value (EV). La mesure du travail effectue exprimee en termes de budget 
autorise pour ce travail. 

Valeur commerciale / Business Value. Benefice net quantifiable emanant d’un effort commercial sous forme tangible 
et/ou intangible. 
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Valeur planifiee (Planned Value, PV) / Planned Value (PV). Le budget autorise alloue au travail prevu. 

Validation / Validation. Assurance qu’un produit, qu’un service ou qu’un resultat satisfait aux besoins du client et des 
autres parties prenantes identifies. Ne pas confondre avec Verification. 

Valider le perimetre / Validate Scope. Processus qui consiste a formaliser I'acceptation des livrables acheves du projet. 

Variance / Variation. Situation reelle differente de la situation escomptee qui est contenue dans le plan de reference 
de base. 

Verification / Verification. Evaluation de la conformite d’un produit, d’un service ou d’un resultat aux regiments, aux 
exigences, aux specifications ou aux conditions imposees. Ne pas confondre avec Validation. 

Voice of the Customer / Voice of the Customer. Technique d'identification utilisee pour definir des produits, des 
services et des resultats qui repondent reellement aux exigences du client, en traduisant ces exigences en specifications 
techniques appropriees pour chaque phase du projet de developpement d’un produit. 
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INDEX 


A 

AC. Voir Cout reel 
Acceptation du risque 
definition, 698 

strategies actives/passives, 443,444,446 
Accord-cadre de services (MSA), 465 
Accords, 460,698. VoiraussiContrary, Accords de niveau 
de service 

cadre de services, 465 

comme donnees d’entree, 78,109,125,141,208,251, 
355,413,496,510,519 
comme donnees de sortie, 489 
Accords de niveau de service (SLA), 78,461,698 
Acheteur 

contrats a I’essai et, 464 
processus d’approvisionnement et, 461 
soumissionnaire retenu, 462 
vendeur et, 460-461 
Actifs. l/o/r Actifs organisationnels 
Actifs. Voir Actifs organisationnels (OPA) 

Actifs organisationnels (OPA) 
categories de, 39-40 

comme donnees d’entree, 79, 84, 94,102,110,117, 
136,141,152,157,170,180,184,189,199, 209,225, 
237, 243,251,260, 281,291,302,314, 324, 331,340, 
348, 355, 369, 383, 391,403,413,422,431,441,450, 
471-472,486, 497, 510, 520, 526, 533 
comme donnees de sortie, 105, 128, 335, 344, 388, 
458, 481,491,501 
definition, 698 

facteurs environnementaux de I'organisation et, 557 
influences du projet et, 37 

processus, politiques internes, et procedures, 40-41 


Action corrective 
definition, 698 

demande de changement pour, 96,112 
Action preventive 
definition, 698 

demande de changement pour, 96,112 
inspection et, 274 
Activite 
definition, 698 
iteratif, 33 

Activite antecedente, 194, 698 
Activite du chemin critique, 698 
Activite iterative, 33 
Activite successeur, 186,188,190, 214 
avances et, 192 
definition, 189, 698 
divers, 194 
retards et, 193 

Activites de developpement de I’esprit d’equipe, 337,341, 
342 

Activites sur noeuds (AON), 218, 698. Voir aussi Methode 
des antecedents 
Adaptation, 2 
definition, 698 

elements du projet, 558-559 
gestion de I'echeancier du projet et, 178 
gestion de I’integration du projet et, 74 
gestion de la qualite du projet et, 276 
gestion des approvisionnements du projet et, 465 
gestion des communications du projet et, 365 
gestion des couts du projet et, 234 
gestion des parties prenantes du projet et, 506 
gestion des ressources du projet et, 311 
gestion des risques du projet et, 400 
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gestion du perimetre du projet et, 133 
vue d’ensemble, 28 

ADR. Voir Modes alternatifs de resolution des conflits 
Affectation prealable des membres de I’equipe, 333 
Affectations des membres de I’equipe de projet, 339,344, 
347 

comme donnees d’entree, 440,469 
comme donnees de sortie, 351,448,452 
Affectations des ressources. Voir Affectations des 
ressources materielles 

Affectations des ressources materielles, 333, 354, 358, 
626 

Alea, 698 

Allocation pour alea. Voir Reserve 
Amelioration 
continue, 275, 276 
qualite, 275, 296 
Amelioration de la qualite 
demarches, 275 
methodes, 296 

Amelioration des risques, 720 
Analyse cout-benefice, 111,119,282, 356,446,698 
Analyse de la liste de controle, 700 
Analyse de la performance technique, 456 
Analyse de la reserve, 202,245, 265, 456,719. Voiraussi 
Reserve pour aleas 

Analyse de la tendance, 111, 126, 170, 227, 263-265, 
356,498, 699 

Analyse de la valeur. Voir Analyse de la valeur acquise 
(EVA) 

Analyse de la valeur acquise (EVA), 111, 226,261,498 
calculs, tableau recapitulate, 267 
Analyse de regression, 126,699 
Analyse de sensibilite, 434,699 
Analyse decisionnelle multicritere, 119,144,534,699 
Analyse des alternatives, 111, 119, 202, 245, 292, 325, 
356,446, 533 
definition, 699 

Analyse des causes originelles (RCA), 111, 292,303,415, 
521,533, 699 

Analyse des documents, 126, 292,415,512 
Analyse des ecarts, 111,126,170, 262-263,699 
Analyse des exigences en communication, 369-370,699 
Analyse des hypotheses et des contraintes, 415,521 


Analyse des parties prenantes, 512,533,699 
Analyse des processus. 292 

Analyse des risques. Voir Processus Effectuer I’analyse 
qualitative des risques; Processus Effectuer I’analyse 
quantitative des risques 

Analyse du diagramme de reseau, 209, 699. Voir aussi 
Calcul au plus tard; Methode du chemin critique; 
Nivellement des ressources 
Analyse du produit, 153,699 
Analyse du reseau. Voir Analyse du diagramme de reseau 
Analyse« make-or-buy», 473,476,698 
Analyse par arbre de decision, 435,699 
Analyse par scenario, 213,227,699 
Analyse qualitative des risques. Voir Processus Effectuer 
I’analyse qualitative des risques 
Analyse quantitative des risques. Voir Processus Effectuer 
I’analyse quantitative des risques 
Analyse SWOT, 415,699 
AON. l/o/7Activites sur noeuds 
Appel a soumissionner (IFB), 700 
Appel d’offres (RFP), 477, 700 
Appel(s) d’offres, 477. Voir aussi Propositions 
soumissionnaire retenu et, 462 
Appetence au risque, 700 
Apprentissage organisationnel, 700 
Approche agile 

considerations relatives a I’adaptation, estimations des 
couts, 234 

processus MaTtriser I’echeancier et, 224 
Approche du cycle de vie, 178,311 
Approche du developpement, 135,180,400, 700 
Approche du developpement de type waterfall, 135,185 
Approches du risque, 420, 518 
Approvisionnement(s) 
clos, 499 

complexity de, 465 
phases, 476 

Approvisionnements clos, 499 
Archive des retours d’experience 
comme donnees de sortie, 128,501 
definition, 700 

Archives des connaissances de I’organisation, 41 
Assurance qualite, 289. VoiraussiProcessus Gerer la qualite 
Ateliers, 145. l/o/'r at/ss/ Ateliers diriges 
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Ateliers diriges, 432 

Attente des parties prenantes, 363 

Attenuation. Voir Attenuation des risques 

Attenuation des risques, 443, 446, 700 

Attribut(s), 149 

Attributs des activites, 700 

comme donnees d’entree, 188, 198, 207, 322, 573, 
576,583 

comme donnees de sortie, 186, 194, 204, 221, 327, 
573,575, 576, 583 
Audit d'approvisionnement, 494,700 
Audit de risques, 456, 458, 700 
Audits, 118, 276,498 

approvisionnement, 494, 700 
qualite, 290, 294-295, 296, 700 
risque, 456, 458, 700 

verification d’un element de configuration et, 118 
Audits qualite, 290, 294-296, 700 
Autorite, 700. Voiraussi Cadres de gouvernance 
Avance(s) 
ajustement, 228 
definition, 192, 700 
exemple de, 192 
retards et, 192-193,214 

B 

BAC. Voir Budget a terminaison 
Base des estimations, 108,204, 700 
comme donnees d’entree, 116,124, 208, 250,430 
comme donnees de sortie, 229,230, 247, 270, 326 
Bases de connaissance de I'organisation. 1/o/rRegistres de 
la base de connaissances de I'organisation 
Battement. Voir Marge 
Benchmarking, 143, 281,700 
Besoins de financement du projet 
comme donnees d’entree, 260 
comme donnees de sortie, 256 
definition, 700 

Besoins en attente du produit, 131,203 
Besoins en financement 
financement du projet, 256 
reference de base des couts, depenses et, 255 


Besoins en ressources. Voir aussi Gestion des ressources 
du projet 

comme donnees d’entree, 208, 242, 331, 355, 413, 
431,470 

comme donnees de sortie, 221,325,500 
definition, 701 

Besoins en ressources des activites. Voir Estimer les 
ressources necessaires aux activites; Besoins en 
ressources 

BIM. l/o/r Modele d’information de construction 
BOK. Voir Corpus des connaissances 
Bonne pratique, 2, 28 

Brainstorming (verbal), 78, 80, 85, 142, 144, 281, 414, 
416,511 

Brainwriting (ecrit), 511 
Budget(s) 

budget echelonne dans le temps, 87, 248, 254 
definition, 701 

Budget a terminaison (BAC), 261,262, 264,430, 701 
Budget echelonne dans le temps du projet, 87,248,254 
Bureau des projets (PMO), 40,48-49,701 
Business case 

comme donnees d’entree, 125,251,469, 509 
definition, 701 

documents business et, 77-78 
projet, 30-32 

Business case du projet, 30-32 

c 

CA. l/o/'rCentre de Consolidation 
Cadres de gouvernance, 43-44 
composants de, 43 

portefeuilles, programmes, projets et, 44 
Calcul au plustard, 210,701 
Calcul au plus tot, 210,701 

Calendrier. Voir Calendrier du projet; Calendriers des 
ressources 

Calendrier du projet, 220, 225, 701 
Calendriers des ressources 

comme donnees d’entree, 199, 208, 225, 323, 331, 
339,440 

comme donnees de sortie, 230,334,344,491 
definition, 701 
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Capacite d’influence, 341,350,357 
Caracteristiques du projet, 47,253 
Categories de risques, 405,417, 701 
Categorisation des risques, 425, 701 
CCB. Voir Comite de maTtrise des changements 
Centre de Consolidation (CA), 161,239,254,701 
Changement(s) 
conteste, 498 
definition, 701 
projets et, 6 

Changement du perimetre, 304,319,402,472 
Changement requis. Voir aussi Demandes de changement 
Changements contestes, 498 
Charge de risque, 701 

Charte. Voir Processus Elaborer la charte du projet; Charte 
du projet; Charte d’equipe 
Charte d’equipe, 319-320, 339, 347, 701 
Charte du projet. Voir aussi Processus Elaborer la charte 
du projet; Liste des principales parties prenantes 
comme donnees d’entree, 83,124,135,140,152,180, 
236, 279, 314, 368, 402, 468, 509, 518 
comme donnees de sortie, 81 
definition, 701 
elements de, 155 
plan de gestion et, 34 
Checklists de la qualite, 292,702 
Chef(s). Voir aussi Chef de projet 
fonctionnel, 53,55, 325, 332 
portefeuille, 13 
programme, 11,29,55 
Chef de portefeuille, 13 
Chef de programme, 11,29,55 
Chef de projet (PM). Voir aussi Competences; competences 
en leadership 
competence de, 56-66 
competences et, 52 
definition, 702 
responsabilites, 73 
role du, 51-52, 66, 551 
sphere d’influence, 52-56 
styles de leadership et, 65 
vue d’ensemble, 51-52 
Chemin critique, 209, 702 

Chemin du reseau, 210, 702. Voir aussi Methode du 
chemin critique (CPM) 


Classe des produits/services, 707 
Client(s). Voir aussi Voice of the Customer 
acheteur devenant le client, 462 
externe, 78 

Cloture de la phase, 126,127,128. Voir aussi Processus 
Clore le projet ou la phase 
Cloture des approvisionnements, formelle, 125,499 
Cloture du projet. Voir aussi Processus Clore le projet ou 
la phase 
documents, 128 
directives, 41 

Code de deontologie et de conduite professionnelle, 3 
Code WBS, 702 
Collaboration 
benefices de, 311-312 
medias sociaux et, 364 
Colocalisation, 340, 343, 702 
Comite de maTtrise des changements (CCB), 115,120,702 
Commission, 702 

Communication. Voir aussi Processus MaTtriser les 
communications; Exigences de I'organisation en 
matiere de communication; Planifier la gestion des 
communications; Gestion des communications du projet 
5 C de la communication ecrite, 361,362-363 
canaux, 45, 209, 368, 370, 383, 391,519, 526, 533 
competences, 363, 384, 527, 534 
conversation, 145,527 
correspondance, 388,496,499 
informel, 341 
interactif, 374 
interculturel, 373 
langage et, 365 
leadership et, 61 
masse, 374 

medias sociaux et, 364,373 
non verbal, 384 
projet, 92,124, 387,390,532 
reussi, deux parties de, 362 
Communication de masse, 374 
Communication(s) du projet, 92,124, 387 
comme donnees d’entree, 390,532 
Communication ecrite, 360,361. Voir aussi Courriel 
5 C de, 361,362-363 
Communication interactive, 374 
Communication interpersonnelle, 374 
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Communication non verbale, 384 
Communication«pull», 374 
Communication«push», 374 
Competence, 319 

Competence en matiere de communication, 363 
Competences 

competences en leadership, 60-63 

competences en management strategique et 

organisationnel, 58-60 

competences en technique de management de projet, 58 

management et, 64 

personnalite et, 66 

styles de leadership et, 65 

vue d’ensemble, 56-57 

Competences. Voir aussi Competences interpersonnelles; 
Competences d’equipe 
chef de projet et, 52 
communication, 363, 384, 534 
influence, 341,350,357 
leadership, 60-63 
management, 702 

management strategique et organisationnel, 58-60 
networking, 386, 534, 717 
PMI Talent Triangle® et, 56-57 
soft, 53, 357 

technique de management de projet, 58 
Competences d’equipe, 144-145 
competences interpersonnelles et, 332-333, 341, 348- 
350,357, 375-376, 386, 392,416,432, 442,451,488, 
527,534 
definition, 702 
risque et, 424 
types de, 80,104 

Competences en leadership, 60-63,350 
passage a I'action, 62-63 
personnes, gestion de, 60 
PMI Talent Triangle® et, 56,57 
politiques, pouvoir et, 62-63 
qualites et, 61-62 
Competences en management, 702 
Competences en management organisationnel, 58-60 
PMI Talent Triangle® et, 56,57 
Competences en management strategique de projet, 58-60 
Competences en networking, 104,534 


Competences en technique de management de projet, 58 
PMI Talent Triangle® et, 56,57 
Competences interpersonnelles, 144-145,153 
competences d’equipe et, 332-333, 341, 348-350, 
357, 375-376,386, 392,416,424,432,442,451,488, 
527,534 
definition, 702 
«soft skills», 53 
types de, 80,104, 534, 552 
Competences interpersonnelles et d’equipe, 702 
Competences strategies, 58-60 
Complexity 

approvisionnement et, 465 
integration et, 68 
projet, 400 

Complexite du projet, 400 
Composants du budget du projet, 255 
Compression de I'echeancier, 228,702 
Compression des delate, 215,703 
Conception des plans d’experiences (DOE), 290 
Condition de declenchement, 448, 518, 725 
Conditions du marche, 243 
Conduite professionnelle, 3 
Conferences audio, 340 

Conferences d’entrepreneurs. Voir Conferences des 
soumissionnaires 

Conferences des fournisseurs. Voir Conferences des 
soumissionnaires 

Conferences des soumissionnaires, 487,699 
Conferences preliminaires a I’offre. Voir Conferences des 
soumissionnaires 
Confidentiality 

confiance et, 282, 414,422,433,442 
information et, 101,102,383 
politiques, 40 
sensibilite et, 371 
Conflit non constructif, 348 
Conformity 

bureaux de projets de type directif et, 48 
considerations relatives a I'adaptation et, 276 
Conformity. Voir aussi Non-conformite 
cout de, 283 

cout de la quality et, 245, 274 
definition, 701 
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satisfaction du client et, 275 
standards gouvernementaux et, 47 
Connaissances, 709. Voir aussi Processus Gerer les 
connaissances du projet 
archives pour, 41 
chef de projet et, 52 
corpus, 1 

explicite, 100, 706 
management de projet et, 16 
Produit, gestion de, 73 
tacite, 100,724 

Connaissances explicites, 100, 706 
Connaissances tacites, 724 
Connectivite, risque et, 424 
Conscience culturelle, 376,527,534 
Conscience politique, 104, 376,386, 527,534 
Conservation et recuperation des informations. Voir 
Registres de la base de connaissances de I’organisation 
Consideration environnementale, 118,546 
Consolidation d'activites, 194,217, 724 
Consolidation des couts, 252, 703 
Consultez les documents Business Analysis for 
Practitioners: A Practice Guide, 7,33,140 
Contenu du produit, 115,131,715 
Contraintes, 28,39,701 
Contraintes du projet. Voir Contraintes 
Contrat(s), 460-461. Voir aussi Accords; Contrat en regie 
(T&M) 

approvisionnement, 464,494, 498,501 
caractere juridique contraignant de, 461 
clause de resiliation, 489 
cloture de, 41,126, 494, 633 
contrat en regie, 472,724 
definition, 702 

frais remboursables, 472,703 
gestion de, 494 
prix forfaitaire, 471,707 
service des achats, 461 
types de, 471-472 
types de paiements et, 476 
Contrat a prix ferme et definitif (FFP), 471,707 
Contrat a prix fixe avec indexation des prix (FPEPA), 471,707 
Contrat a prix fixe avec interessement (FPIF), 471,707 
Contrat d'achat, 461 


Contrat d'approvisionnement, 464, 494,498,501 
Contrat en regie (T&M), 472,724 
Contrat en regie avec honoraires fixes (CPFF), 472,703 
Contrat en regie avec interessement (CPIF), 472 
Contrat en regie avec prime a la performance (CPAF), 472 
Contrats a frais remboursables, 472,703 
Contrats a prix forfaitaire, 471,707 
Controle/maitrise, 107,702 
Convergence des chemins, 194,712 
Conversation, 145,392, 527 
C0Q. l/o/y Cout de la qualite 
Corpus des connaissances (BOK), 1,2,69 
Corpus des connaissances en management de projet, 1, 
2, 69,716 

Correction des defauts, 96,112,704 
Correspondance, 388,496,499 
Courants, acronymes, 696-697 
Courriel, 78, 311,333, 340, 361,362, 373, 374, 375, 376, 
377,385 

Cout(s). Voir Cout reel 
defaut, 274, 275, 282, 303 
indirect, 246,261 

Cout de la qualite (COQ), 245, 274, 282-283, 703 

Cout de reste a faire (ETC), 706 

Cout reel (AC), 261,698 

Couts de defauts, 274, 275, 282, 303 

Couts indirects, 246,261 

CPAF. Voir Contrat en regie avec prime a la performance 
CPFF. l/o/r Contrat en regie avec honoraires fixes 
CPI. Voir Indice de performance des couts 
CPIF. Voir Contrat en regie avec interessement (CPIF) 

CPM. l/o/r Methode du chemin critique 
Criteres, 703 

Criteres d’acceptation, 154,698 
Criteres de selection des sources, 473-474, 478-479, 
485, 723 

Culture. Voir Culture de I’organisation 
Culture du client, 101 

Culture organisationnelle, 38. Voir aussi Diversity culturelle 
CV. Voir Ecart de cout 

Cycle de vie. Voir aussi Cycle de vie iteratif; Cycle de vie 
predictif; Cycle de vie du produit; Cycle de vie du projet 
attributs et, 20 
definition, 710 
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developpement, 19,74 
incrementiel, 19,708 
iteratif, 19,151,709 
predictif, 19, 714 

Cycle de vie du developpement, 19,74 
Cycle de vie du produit 
cout de la qualite et, 245 
definition, 715 

Cycle de vie du projet, 19,547-549 
adaptatif, 19,131,698 
definition, 716 

plan de management du projet et, 135 
predictif, 19,131,714 
Cycle de vie hybride, 19 
Cycle de vie incrementiel, 19,708 
Cycle de vie iteratif, 19,151,709 
Cycle de vie predictif, 19,131,714 
Cycle Planifier-Derouler-Controler-Agir (PDCA), 275 
Cycles de vie adaptatif, 19,698 
Cycles de vie de type waterfall, 19 

D 

Date de debut, 723 
Date de debut au plus tard, 210,709 
Date de debut au plus tot (ES), 210,705 
Date de fin, 210,211,706 
Date de fin au plus tard, 210,709 
Date de fin au plus tot (EF), 210,705 
Date des donnees, 704 
Date imposee, 708 
DD. Voir Liaison debut-debut 
Decision de produire ou d’acheter, 241 
Decisions « make-or-buy», 473,479,710 
Declencheurs de risque, 417,448 
Decodage/encodage des messages, 371 
Decodage/encodage des messages, 371 
Decomposition, 185. l/o/rat/ss/'Organigramme destravaux 
du projet (WBS) 
composants du WBS et, 160 
definition, 704 
en lots de travaux, 158,316 
Defaut(s) 
definition, 704 
histogrammes et, 293, 304 


Demande client, 78,546 
Demande d'information (RFI), 477, 718 
Demande(s) de changement. Voir aussi Demande 
de changement approuvee; Plan de gestion des 
changements; processus MaTtriser les changements; 
Changements demandes 
comme donnees d’entree, 117,301 
comme donnees de sortie, 96,112,166,170,186,220, 
228, 269,296, 306, 334, 343, 350,357, 393,447,451, 
457,479,489,499,514, 528,535 
components requiring, 171, 186, 221, 229, 287, 297, 
351,358, 387, 393, 490, 500, 515, 529 
definition, 700 
outils et, 119 

references de base du projet et, 115 

revue des demandes de changement approuvees, 305 

suivi du statut, 124 

types de, 96,112 

Demande de changement approuvee, 115 
audits qualite et, 295 

comme donnees d’entree, 93,300, 301,495,496 
comme donnees de sortie, 120 
reference de base de I’echeancier et, 229 
Demande de devis (RFQ), 477, 719 
Demande du marche, 78 
Deming, W. Edwards, 275 
Deontologie, 3 

Dependance. Voir aussi Relation logique 
definition, 704 
obligatoire, 191,710 
Dependences externes, 192,706 
Dependences facultatives, 191,705 
Dependances internes, 192 
Dependances obligatoires, 191,710 
Derive du perimetre, 154,168,182, 722 
Design for X (DfX), 295 
Detectabilite, risque et, 424,426 
Determination des dependances 
dependances externes, 192 
dependances facultatives, 191 
dependances internes, 192 
dependances obligatoires, 191 
integration et, 191-192 
Developpement de I’esprit d’equipe, 341 
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Developpement de I’esprit d’equipe a I’echelle de 
Tuckman, 338 

Developpement de logiciels, 84,252 
seances JAD et, 145 
storyboards et, 147 
Devis, 477 

DF. Voir Liaison debut-fin 
DfX. Voir Design for X 
Diagramme a bulles, 425-426 
Diagramme de controle, 304, 702 
Diagramme de Gantt, 217,707 
Diagramme de reseau d’echeancier a echelle de temps, 218 
Diagramme de reseau du projet 
comme donnees d’entree, 208 
comme donnees de sortie, 194,218 
definition, 717 

description de, 193-194, 218 
retard et, 193 

Diagramme du travail restant, 226 
Diagramme du travail restant (« burndown ») sur les 
iterations, 226 

Diagramme en arete de poisson, 293, 707. Voir aussi 
Diagrammes cause-effet 
Diagramme Tornado, 434,436,725 
Diagrammes a jalons, 218 
Diagrammes cause-effet, 293,294, 304, 700 
Diagrammes d’affinity, 144, 293,698 
Diagrammes d’influence, 436,708 
Diagrammes d'lshikawa, 293 
Diagrammes de correlation, 293,304 
Diagrammes de flux, 284,293,707 
Diagrammes de flux, processus, 23 
Diagrammes de flux des processus, 23,284 
Diagrammes hierarchiques, 316,425-426 
Diagrammes matriciels, 284,293, 710 
Dictionnaire du WBS, 162,726 
Differends, 498 
Dimensions du projet, 178 
Directives, approvisionnement, 471 
Distribution beta, 245 
Distribution de probability, 432 
cumulative (courbe en S), 433 
diagramme d’influence et, 436 
jalon cible et, 214 
risques de variability et, 399 
simulation et, 213 


Distribution triangulaire, 201,245 
Divergence des chemins, 194,712 
Diversity 

culturel, 311,338 
partie prenante, 506 
Diversity culturelle, 338,363 

Document(s). Voir aussi Documents business; Documents 
d’approvisionnements; Documents du projet 
appel d’offres, 477, 485, 699 
business, 29-30 
business case du projet, 30-32 
operationnel, 128 

test et evaluation, 296, 300, 303-304, 306, 724 
Documentation. Voir aussi Retours d’experiences; 
Documents d'approvisionnements; Documentation des 
exigences; Communication ecrite 
documents d’appel d’offres, 699 
evaluation de la performance du vendeur, 501 
revues, 705 

technique, 125, 415, 499 

Documentation des exigences, 147-148. Voir aussi 
Processus Recueillir les exigences; Contrat(s) 
comme donnees d’entree, 124, 152, 157, 165, 169, 
280, 314, 368,412,470, 485, 495, 510 
comme donnees de sortie, 97,147-148,155,162,167, 
171,480,491 
definition, 719 

Documentation sur revaluation de la performance du 
vendeur, 501 

Documents business, 29-30 
business case et, 77-78 

comme donnees d’entree, 125,141,251,469, 509 
cycle de vie du projet et, 30 
definition, 559 

management de projet, 29-30 
Documents d’appel d’offres, 477, 485,699 
Documents d’approvisionnement 
comme donnees d’entree, 125,413 
contrat d’approvisionnement, 464, 494,498, 501 
definition, 714 

Documents d’approvisionnement, 485 
comme donnees d’entree, 496 
comme donnees de sortie, 499 
comparaison de, 481 
definition, 714 
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Documents devaluation et de test, 296, 300, 303-304, 
306,724 

Documents du projet 

comme donnees d’entree, 92-93,101,108,116,124, 
141,152,157,165,169,188,198, 207-208,225, 242, 
250, 260,280, 291,300, 314, 322,331,339, 347, 354, 
368,382,390,403,412-413,421,430-431,440,450, 
455, 469-470, 484-485, 495, 510, 519, 525, 532 
comme donnees de sortie, 97,113,120,127,128, 155, 
162, 167, 171, 194, 204, 221, 230, 247, 256, 270, 287, 
297, 306, 320, 327, 335, 344, 351, 358, 378, 387, 393, 
418,427,436,448,452,458,480,491,500,515,529,536 
plan de management du projet et, 89,559 
Documents operationnels, 128 
DOE. Voir Conception des plans d’experiences 
Domaines de connaissance, 23-25,553 
groupes de processus et, 24-25, 556 
principaux composants du PMBOK® Guide e t, 18 
representation graphique, 24-25, 556 
vue d’ensemble, 23-25 

Domaines de connaissance en management de projet, 
23-25,553, 716 

Donnee(s) d’entree. Voiraussi processus specifique 
definition, 708 

processus du management de projet et, 22,555 
Donnee(s) de sortie. Voiraussi processus specifique 
definition, 712 

processus du management de projet et, 22,555 
Donnees. Voiraussi Donnees de performance d’execution 
definition, 704 
vue d’ensemble, 26-27 
Donnees de I’echeancier, 721 
comme donnees d’entree, 225 
comme donnees de sortie, 220,230 
Donnees de performance d’execution, 26 
comme donnees d’entree, 165, 169, 225, 260, 301, 
355, 390, 456,496, 532 
comme donnees de sortie, 95 
definition, 726 
Donnees historiques 
definition, 708 

registre des retours d’experience et, 41,74 
revues, 253 

Dossier d'approvisionnement, 501 


Dossiers du projet, 41,79,109, 388, 494 

Droits de propriety intellectuelle, 470,480,483,485,491,495 

Droits legaux, 512 

DU ou DUR. Voir Duree 

Duree (DU ou DUR), 705. Voiraussi Duree la plus probable; 

Duree optimiste; Duree pessimiste 

Duree de I’activite, 698 

Duree des iterations, 182 

Duree la plus probable, 201 

Duree optimiste, 201 

Duree reelle, 698 

E 

EAC. l/o/rEstime aterminaison 
Ecart, 725 

Ecart a terminaison (VAC), 725 
Ecart de cout (CV), 262, 703 
Ecart de delais (SV), 262,722 
Echantillonnage par attributs, 274,699 
Echantillonnage statistique, 303,724 
Echeancier 
a la demande, 177 

alternatif, avec une liste des besoins en attente, 177 
vue d’ensemble, 176 

Echeancier(s), 721. Voir aussi Processus MaTtriser 
I'echeancier; Echeancier directeur; Echeancier du 
projet; Modele d’echeancier 

Echeancier a jalons, 711. Voiraussi Echeancier directeur 
Echeancier acquis (ES), 233 
Echeancier directeur, 217,710 
Echeancier du projet 

comme donnees d’entree, 93,225,242,250,314,331, 
339,355,440,484, 519 

comme donnees de sortie, 217-219, 230, 256, 335, 
344, 378, 387, 448 
definition, 717 

Echeanciers et demandes de paiement, 501 

Echelles d’impact, risque et, 426 

Ecoute active, 104, 363, 372, 381,386, 534 

EEF. l/o/r Facteurs environnementaux de I'organisation 

EF. Voir Date de fin au plus tot 

Effort, 705 

Effort unitaire, 705 
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Elaboration de I’echeancier. Voir Processus Elaborer 
I’echeancier 

Elaboration progressive, 147,185,186,565, 715 
Element de I’organigramme des travaux du projet, 726 
Elements 

communication, 375 
projet, 558-559 

Elements de configuration, controle des modifications et, 118 
Elements de management, 44-45 
Elements du projet, adaptation, 558-559 
Emergentes, pratiques 
gestion de I'echeancier du projet et, 177 
gestion de I’integration du projet et, 73 
gestion de la qualite du projet et, 275 
gestion des approvisionnements du projet et, 463-464 
gestion des communications du projet et, 364 
gestion des couts du projet, 233 
gestion des parties prenantes du projet et, 505 
gestion des ressources du projet et, 310-311 
gestion des risques du projet et, 398-399 
gestion du perimetre du projet et, 132 
EMV. l/o/VValeur monetaire attendue (EMV) 

Engagement des parties prenantes du projet, 24,503-506 
considerations relatives a I’adaptation, 506 
definition, 717 

environnements agiles/adaptatifs et, 506 
principaux concepts pour, 504-505 
tendances et pratiques emergentes, 505 
vue d’ensemble, 503-504 
Enonce des travaux (SOW), 462, 468, 469 
approvisionnement, 477-478,485 
definition, 724 

Enonce des travaux d’approvisionnement, 477-478,485,715 
Enonce des travaux du projet. Voir Enonce des travaux 
Enonce du perimetre. Voir Enonce du perimetre du projet 
Enonce du perimetre du projet 
comme donnees d’entree, 157 
comme donnees de sortie, 154,161 
definition, 717 
elements de, 155 
Enquetes, 143, 303, 511,718 
Entrepreneur(s), 465. Voir aussi Vendeur(s); Sous-traitants 
Entretiens, 80, 85,142, 282,414,432, 709 


Environnement, 37-49, 133. Voir aussi Environnements 
adaptifs; Environnements agiles; Facteurs 
environnementaux de I'organisation; Globalisation/ 
environnement mondial 
actifs organisationnels, 39-41 
elements de management, 44-45 
projet, 365, 371 
reglementaire, 465 
systemes de I’organisation, 42-44 
types de structures organisationnelles, 45-47 
vue d’ensemble, 37 

Environnement de projet de type matriciel, 329 
Environnement du projet, 365, 371. Voir aussi 
Environnements adaptatifs; Environnements agiles 
Environnement organisationnel, 10 
Environnements adaptatifs 
gestion de I’echeancier du projet et, 178 
gestion de I'integration du projet et, 74 
gestion de la qualite du projet et, 276 
gestion des approvisionnements du projet et, 465 
gestion des communications du projet et, 365 
gestion des couts du projet et, 234 
gestion des parties prenantes du projet et, 506 
gestion des ressources du projet et, 311 
gestion des risques du projet et, 400 
gestion du perimetre du projet et, 133 
Environnements agiles 
gestion de I'echeancier du projet et, 178 
gestion de I'integration du projet et, 74 
gestion de la qualite du projet et, 276 
gestion des approvisionnements du projet et, 465 
gestion des communications du projet et, 365 
gestion des couts du projet et, 234 
gestion des parties prenantes du projet et, 506 
gestion des ressources du projet et, 311 
gestion des risques du projet et, 400 
gestion du perimetre du projet et, 133 
Equipe(s). Voir aussi Equipes colocalisees; Processus 
Developper I’equipe de projet; Equipe de management 
de projet; Equipe(s) de projet 
auto-organise, 310, 722 
chef de projet et, 51 
gestion de, 311 
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hautement performant, 346 
recrutement des membres, 311 
virtuel, 311,333,340, 725 

Equipe de management de projet, 716. Voir aussi 
Equipe(s) projet 

Equipe(s) projet, 717. Voir aussi Processus Diriger I’equipe 
de projet; Equipe(s); Equipes virtuelles 
affectations, 198,208 
management des ressources, 319 
objectifs de developpement, 338 
Equipes auto-organisees, 310, 722 
Equipes colocalisees, 340 
Equipes distributes, 311 
Equipes virtuelles, 311,333, 340, 725 
ES. Voir Date de debut au plus tot 
Escalade, 355 
menaces et, 442 
opportunity et, 444 
Escalade des risques, 545, 720 
Estimation(s). Voir aussi Estimation paranalogie; Base des 
estimations; Estimations independantes; Estimation 
parametrique; Estimation a trois points 
cout independant, 479 
definition, 706 
independant, 708 
Estimation ascendante, 324 
definition, 700 
description de, 202,244 
Estimation a trois points, 201,244-245,724 
Estimation par analogie, 200,244,324,699 
Estimation parametrique, 200-201,244,324,712 
Estimations de durees, 203. Voir aussi Processus Estimer 
la duree des activites 
comme donnees d’entree, 208,412,430 
comme donnees de sortie, 221 
Estimations de la duree d’une activite, 698. Voir aussi 
Estimer la duree des activites 
Estimations des couts. Voir aussi Processus Estimer les couts 
comme donnees d’entree, 250,323, 412,430 
comme donnees de sortie, 246, 256,270 
independant, 479,485 
Estimations independantes, 708 
Estimations independantes des couts, 479,485 
Estime a terminaison (EAC), 264-265, 706 


Etablissement des rapports du projet, 385 
Etat futur, etat de transition et, 6 
ETC. 1/o/rCout du reste a faire 
Etude de faisabilite, 20, 30-32, 77,125, 555 
Etude de faisabilite economique, 30-32,125 
Etude du marche, 473 
EV. 1/o/rValeur acquise 
EVA. Voir Analyse de la valeur acquise 
Evaluation de la performance. Voir Evaluations de la 
performance de I'equipe 

Evaluation de la qualite des donnees relatives aux risques, 
423,720 

Evaluation des styles de communication, 375,701 
Evaluations, personnes et equipe, 342 
Evaluations de I’equipe, 342 
Evaluations de la performance, 126,344,351 
Evaluations de la performance du projet, 342 
Evaluations de performance de I'equipe, 339,343,347 
Evaluations du produit. Voir Documents de test et 
d’evaluation 

Evitement, risque global du projet et, 445 
Evitement du risque, 443, 720 
EVM. l/o/7Gestion de la valeur acquise 
Exactitude, 182, 238, 698 
Exclusions du perimetre, 154 
Executer, 706 

Execution du projet. 1/o/rGroupe de processus d’execution 
Exigence(s). Voir aussi Exigences de haut niveau; 
Exigences du produit 
business, 148 
classifications, 148 

communication organisationnelle, 369, 383, 391, 520, 

525,533 

definition, 719 

fonctionnel, 118,148 

legal, 78, 369, 370 

non fonctionnel, 148 

partie prenante, 148 

projet, 148 

qualite, 148,718 

solution, 148 

transition et preparation, 148 
transversal, 145 
Exigences business, 148 
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Exigences de haut niveau, 80,81,135,140,149,402 
Exigences de I'organisation en matiere de communication, 
40,102, 369,383,391,520,525,533 
Exigences de la solution, 148 
Exigences de qualite, 148,718 
Exigences des parties prenantes, 148 
Exigences du client, 20,273 
Exigences du produit 
brainstorming et, 142 
facilitation et, 145 

matrice de tragabilite des exigences et, 93,148, 280, 
470 

propre au secteur, 140 
reunion, 552 
Exigences du projet, 148 

Exigences du projet en matiere de communication. Voir 
Analyse des exigences en communication 
Exigences fonctionnelles, 118,148 
Exigences juridiques, 78,369, 370 
Experts du domaine concerne (SME), 54, 55, 104. Voir 
Jugement a dire d’expert 
brainstorming et, 80,85,281 
entretiens et, 142, 282,414 
facilitation et, 145 
Exploitation des risques, 721 
Exposition au risque du projet, evaluation de, 436 
Exposition aux risques, 398. Voiraussi Processus Planifier 
les reponses aux risques; Rapport sur les risques 
definition, 721 

evaluation du projet global, 436 

F 

Facilitation, 80, 86,104,145, 381,442 
Facteurs cles pour I’echeancier, 464 
Facteurs critiques de succes, 31 
Facteurs environnementaux de I'organisation (EEF), 37- 
39,557 

actifs organisationnels et, 557 
comme donnees d’entree, 78, 84, 93, 101, 109, 117, 
135,141,152,157,180,184,189,199, 209,236-237, 
243, 251,280, 301,315, 323, 331,339, 348, 368, 383, 
391,403,413,422,431,441,470,486, 497, 510,519, 
526, 533 


comme donnees de sortie, 335,344,351 
definition, 706 
externe a I’organisation, 39 
influences du projet et, 37 
interne a I’organisation, 38 
FD. Voir Liaison fin-debut 
Feuille de route du produit, 215-216 
FF. Voir Liaison fin-fin 
FFP. l/o/r Contrat a prix ferme et definitif 
Fiches de controle, 302,700 
Financement, 253 

Forces, faiblesses, opportunity et menaces. 1/o/rAnalyse SWOT 
Formation, turbulence, normalisation, execution, 
dissolution, 338 

Formation interdisciplinaire, 337 
Formats de type texte, roles et responsabilites, 317 
Formats des rapports, 182, 239,408, 455, 525 
Formulaires role-responsabilite-autorite, 317 
Fournisseur. l/o/rVendeur(s) 

Fournisseur. l/o/rVendeur(s) 

Fournisseur(s). Voir aussi Relation acheteur-vendeur; 
Gestion des approvisionnements du projet 
acheteur et, 460-461 
definition, 722 
partenariat avec, 275 
prequalifie, 501 
termes pour, 461 

FPEPA. 1/o/rContrat a prix fixe avec indexation des prix (FPEPA) 
FPIF. l/o/r Contrat a prix fixe avec interessement 
FPP l/o/r Contrat a prix ferme et definitif 

G 

Generalement reconnu, 2 
Gestion de I’echeancier du projet, 24,173-178 
considerations relatives a I’adaptation, 178 
definition, 717 

environnements agiles/adaptatifs et, 178 
principaux concepts, 175 
processus, 173 

tendances et pratiques emergentes, 177 

vue d’ensemble de, 174 

vue d’ensemble de I’echeancier, 176 
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Gestion de (’integration du projet, 23. Voiraussi processus 
specifique 

considerations relatives a I’adaptation, 74 
definition, 716 

environnements agiles/adaptatifs, 74 
principaux concepts, 72 
processus de, 70 

tendances et pratiques emergentes, 73 
vue d’ensemble, 69-71 

Gestion de la qualite. Voir Gestion de la qualite du projet 
Gestion de la qualite du projet, 24, 271-276. Voir aussi 
Plan de gestion de la qualite 
considerations relatives a I’adaptation, 276 
definition, 717 

environnements agiles/adaptatifs et, 276 
interrelations, principals, 273 
principaux concepts pour, 273-275 
tendances et pratiques emergentes, 275 
vue d’ensemble, 271-273 
Gestion de la valeur acquise (EVM) 
definition, 705 
expansion de, 233 

reference de base des couts pour, 254 
regies de mesure de performance, 182,239,254 
Gestion des approvisionnements du projet, 24, 459-465 
considerations relatives a I'adaptation, 465 
definition, 717 

environnements agiles/adaptatifs et, 465 
principaux concepts pour, 460-462 
processus de, 459 

tendances et pratiques emergentes, 463-464 
vue d’ensemble, 460 

Gestion des benefices, reussite du projet et, 546-547 
Gestion des communications, techniques et approches, 381 
Gestion des communications du projet, 24,359-365 
considerations relatives a I'adaptation, 365 
definition, 715 

environnements agiles/adaptatifs et, 365 
principaux concepts pour, 360-363 
processus de, 359 

tendances et pratiques emergentes, 364 
vue d’ensemble, 360 

Gestion des communications electroniques, 385 


Gestion des conflits, 61,80, 86, 341,348-349, 386, 527 
Gestion des connaissances, 133,365 
idees fausses, 100 
outils et techniques, 103 
produit, 73 
projet, 73 

Gestion des couts du projet, 24, 231-234 
considerations relatives a I’adaptation, 234 
definition, 715 

environnements agiles/adaptatifs et, 234 
principaux concepts pour, 233 
processus de, 231 

tendances et pratiques emergentes, 233 
vue d’ensemble, 231-232 
Gestion des exigences: A Practice Guide, 132 
Gestion des reclamations, 498,701 
Gestion des reseaux sociaux, 385 
Gestion des ressources du projet, 24,307-312. Voiraussi 
Employes 

considerations relatives a I’adaptation, 311 
definition, 717 

environnements agiles/adaptatifs et, 311-312 
principaux concepts pour, 309-310 
tendances et pratiques emergentes, 310-311 
vue d’ensemble, 307-309 
Gestion des risques du projet, 24, 395-400 
considerations relatives a I’adaptation, 400 
definition, 717 

environnements agiles/adaptatifs et, 400 
principaux concepts pour, 397-398 
processus de, 395 

tendances et pratiques emergentes, 398-399 
vue d’ensemble, 396 
Gestion des risques integree, 399 
Gestion du perimetre du projet, 23,129-133 
considerations relatives a I’adaptation, 133 
definition, 717 

environnements agiles/adaptatifs et, 133 
principaux concepts pour, 131 
processus, 129 

tendances et pratiques emergentes, 132 
vue d’ensemble, 130 
Gestionnaire des ressources, 719 
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Globalisation/environnement mondial 
diversity culturelle et, 338 
equipes virtuelles/distribuees et, 311 
facteurs internationaux, 332 
influences culturelles et, 39 

Gouvernance, 28, 465. Voir aussi Gouvernance 
organisationnelle; Gouvernance du projet 
Gouvernance des portefeuilles, programmes, et projets: 

A Practice Guide, 44 
Gouvernance du projet 
definition, 44, 715 

gouvernance organisationnelle et, 545 
Gouvernance organisationnelle 
cadres, 43-44 

gouvernance du projet et, 545 
Graphique a barres, 217,699 
Graphique a barres logique, 218 
Grille d’influence/impact, analyse des parties prenantes, 512 
Groupe(s). Voir aussi Groupes de discussion; Groupes de 
processus de management de projet, 
projets et, 4 

Groupe de processus d’execution, 23,595-611 
definition, 706 
processus de, 596 
vue d’ensemble, 595 

Groupe de processus d’initialisation, 23,561-564 
definition, 708 
limites du projet et, 562 
vue d’ensemble, 561-562 
Groupe de processus de cloture, 23,633-635 
definition, 701 

donnees d’entree et donnees de sortie, 634 
vue d’ensemble de, 633 
Groupe de processus de maTtrise, 23,613-632 
definition, 711 
processus de, 614 
vue d’ensemble, 613 

Groupe de processus de planification, 23,565-594 
definition, 713 
processus de, 566 
vue d’ensemble, 565-566 
Groupes de discussion, 80, 85,142, 707 
Groupes de processus. I Voir Groupe de processus de 
management de projet 


Groupes de processus de management de projet, 23, 
554-556 

cartographie des domaines de connaissance et, 24-25, 
556 

categories de, 23 
definition, 716 

interactions projet/phase et, 555 
PMBOK principaux composants et, 18 
Guide du Corpus des connaissances en management de 
projet (Guide PMBOK®) 
composants de, 17-18 
developpementde, 69 
fondement et cadre pour, 541 
objectif de, 2 

vue d’ensemble des standards industriels, 1-2 

H 

Histogramme des ressources, 719 
Histogrammes, 293,304, 708 
Hypothese(s), 33,699 

I 

ID. l/o/rldentifiant d’activite 
Identifiant d’activite (ID), 188 
Identifiant du WBS, 186 

Identification des parties prenantes, 367,504,510,514,532 
Identification des risques. l/o/'rProcessus Identifier les risques 
Identifier les risques. l/o/r at/ss/ Registre des risques 
analyse de la reserve et, 265 
Analyse SWOT et, 415 
estimation des couts et, 246,247 
liste de, 417 

organigramme des risques et, 405 
perception du risque et, 420 
reserves pour alea et, 245 
IFB. Voir Appel a soumissionner 
Impact de risque. Voir aussi Matrice de probability et 
d’impact 

Impact ecologique, 78 

Implementing Organizational Project Management: 

A Practice Guide, 17 
Importance du projet, 400 
Inactivity, risque et, 424 
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Incertitude, 398, 415 
Incertitude (connu-inconnu), 202, 245 
Indicateurs cle de performance (KPI), 95,389 
Indicateurs de performance de la valeur acquise, 228 
Indice de criticite, 434 

Indice de performance a terminaison du projet (TCPI), 266, 
268,724 

Indice de performance des couts (CPI), 263,703 
Indice de performance des delais (SPI), 182, 226, 233, 
263,722 

Industrie, chef de projet et, 55 
Inflation, 243 

Influence, direction de, 513 
Information sur la performance d’execution, 26,357 
comme donnees d’entree, 109,535 
comme donnees de sortie, 166, 170, 228, 305, 392, 
457,499 
definition, 726 

Informations, 708. Voir aussi Documentation; Donnees 
historiques; Information du projet 
confidentialite/sensibilite de, 371 
donnees du management de projet et, 26-27 
performance d’execution, 26 
urgence de besoin en, 370 
Initialisation du projet 
contexte pour, 7-9 
processus, procedures et, 40 
Initialisation du projet 
contexte, 7-9 
definition, 716 
Inspection(s) 
definition, 708 

description de, 166,303,498 
planification, 285 
prevention et, 274 

Integrality des cycles de vie planifies. Voir Cycle de vie 
predictif 

Integration, 66-68. Voir aussi Gestion de I’integration 
du projet 
complexity et, 68 
niveau cognitif et, 67 
niveau de processus et, 67 
niveau du contexte et, 67 
vue d’ensemble, 66 
Integration. Voir Integration 


Intelligence emotionnelle (El), 310,349,705 
Interdependences, 14,16,102-103 
IRR . Voirlaux interne de rentabilite 

J 

JAD. Voir Seances Joint application design/development 
(JAD) 

Jalon, 711 

JIT. Voir Juste a temps 

Joint venture, 444,445,476 

Journal, 710. Voir aussi Journal des points a traiter 

Journal des hypotheses 

comme donnees d’entree, 108, 124, 141, 152, 188, 
198, 207, 280, 323,412,421,430,495, 519 
comme donnees de sortie, 81,97,155,194, 204, 221, 
230, 247, 270, 320, 327, 358, 418,427, 448, 458, 515 
definition, 699 
Journal des points a traiter 

comme donnees d’entree, 124, 347, 354, 382, 390, 
412,455, 510,519, 525, 532 
comme donnees de sortie, 96,113,297, 306, 351,358, 
387, 393, 418, 427,452, 458, 515, 529, 536 
definition, 709 

Jugement. Voir Jugement a dire d’expert 
Jugement a dire d’expert, 58, 85, 94,102,110,118,126, 
136,142,153,158,181,184, 200, 237, 243,252, 260, 
281,315, 324, 369,391,404,414,422, 431,441,451, 
472, 487, 497, 511, 520, 526, 706. Voir aussi Experts 
specialises dans le domaine (SME) 

Juridictions gouvernementales, 487. Voir aussi Organes 
de regimentation 
Juste a temps, 234,310 

K 

Kaizen, 310 

KPI. l/o/r Indicateurs cle de performance 

L 

Langue, 365 

Leader(s), quality et competences de, 61-62 
Leadership, 534 
gestion comparee a, 64-66 
styles, 65 
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Lean Six Sigma, 275 

Lexique. Voir Lexique PMI des Termes lies au Management 
de Projet 

Lexique PMI des Termes lies au Management de Projet, 3 

LF. Voir Date de fin au plus tard 

Liaison debut-debut (DD), 190,724 

Liaison debut-fin (DF), 190,723 

Liaison fin-debut (FD), 190, 707 

Liaison fin-fin (FF), 190, 706 

Lien logique, 710. Voir aussi Methode des antecedents 
(PDM); Relation d’anteriorite 

Lien logique prefere/lien logique preconise, 191. Voir aussi 
Dependances facultatives 

Liens avec les procedures de I’organisation, 182,239 

Limites decontrole, 702. l/o/rat/ss/Limites de specifications 

Limites de specifications, 723. l/o/r at/ss/SeuiIs de controle 

Limites du projet, 562 

Lissage des ressources, 211,720 

Liste d’activites 

comme donnees d’entree, 188,198, 207,322 
comme donnees de sortie, 185,194 
definition, 698 

Liste(s) de controle, 85,302,414. Voir aussi Checklists de 
la qualite 

Liste de veille, risques et, 423,427, 440,455 
Liste des besoins en attente des iterations, 203,226 
Liste des jalons 

comme donnees d’entree, 92,108,124,188,198,208, 
430,469, 495 

comme donnees de sortie, 186,194,480 
Liste des principales parties prenantes, 81,314,368,509 
Listes des vendeurs 
preapprouve, 471 
prequalifie, 501 

Listes des vendeurs preselectionnes, 471 
Livrable(s). Voir aussi Resultat 
accepte, 166, 698 

comme donnees d’entree, 101,125, 301 
definition, 704 

donnees de sortie comme, 21,95,154 
management de projet et, 16,22 
projets et, 5 

structure du WBS et, 160 
verifie, 165, 305, 725 
Livrables acceptes, 166,698 


Livrables verifies, 165,305,725 
LoE. l/o/r Niveau d'effort 
Logiciel. l/o/r at/ss/' Logiciel de planification 
management de projet, 188,194, 377, 385 
simulation et, 433 
structure du WBS et, 159 
technology de I’information, 38 
Logiciel de management du projet, 188,194,377,385 
Logiciel informatique. 1/o/rLogiciel de planification; Logiciel 
Logiciels de planification, 38,95,216,227,357 
Logique du reseau, 218,711 
Logistique, 464 

Loi des rendements decroissants, 197 
Lot de planification, 161, 713. Voir aussi Centre 
de consolidation 
Lots de travaux, 157 
decomposition et, 158,183,185 
definition, 726 
description de, 161 
elaboration progressive et, 186 
niveau de detail et, 158 
LS. Voir Date date de debut au plus tard 

M 

MaTtrise de I’echeancier. Voir Processus MaTtriser 
I’echeancier 

MaTtrise de la configuration, 115,118 
MaTtrise des changements. Voir aussi Effectuer la gestion 
integree des changements 
outils, 118-119, 700 
procedures, 40 
reunions, 120 

MaTtrise des couts. Voir Processus MaTtriser les couts 
MaTtrise des couts du projet. Voir Processus MaTtriser les 
couts 

MaTtriser les changements. Voir Processus Effectuer la 
gestion integree des changements 
Majorite, 144 

Management, l/o/rat/ss/Gestion des conflits; Management de 
portefeuille; Management de programme; Management 
de projet; Gestion de la qualite du projet 
chaTne d’approvisionnement, 464 
connaissances du projet, 73 
equipe, 311 
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leadership compare a, 64-66 
reseaux sociaux, 385 
reunions et, 80, 86,386 
risque, 399,463 
Management de portefeuille 
definition, 15, 714 
description de, 15 

management de programme et, 11,12 
strategies organisationnelles et, 16 
Management de portefeuille, Le standard pour, 3,15,33 
Management de programme 
definition, 715 
description de, 14 
management de portefeuille et, 11 
Management de programme, Le standard pour le, 3,14,33 
Management de projet. Voir aussi Management de projet 
organ isationnel 
definition, 10, 716 
domaines de connaissance, 23-25 
groupes de processus dans, 23-25 
importance de, 10-11 
processus, 22 

Management de projet organisationnel (0PM) 
cadre de gouvernance, 44 
definition, 544 
objectif de, 17 
strategies et, 16-17 

Management des delais. Voir Gestion de I’echeancier 
du projet 

Management des ressources humaines. Voir Gestion des 
ressources du projet 

Management strategique, PMI Talent Triangle® et, 56,57 

Managing Change in Organizations: A Practice Guide, 6 

Marge, 191,210, 707,725 

Marge libre, 707 

Marge totale, 191,210, 725 

Matrice devaluation de I’engagement des parties 
prenantes, 521-522,723 
Matrice de probability et d'impact, 425 
definition, 714 
grille de notation et, 408 
Matrice de tragabilite des exigences 
comme donnees d’entree, 93, 116, 165, 169, 280, 
470,496 


comme donnees de sortie, 148-149, 155, 167, 171, 

287,480,491,501 

definition, 719 

exemple de, 149 

Matrice des responsabilites (RAM), 317 
Matrice des responsabilites (RAM), 720 
Matrice RACI, 317,718 

Matrice Realisateur, Approbateur, Consulte et Informe 
(RACI) 317,718 
Matrices de tragabilite, 40 
Medias, choix de, 381 
Medias sociaux, 364, 374 
Megaprojets, 11,463 
Meilleures pratiques 
benchmarking et, 143,281,399 
dependances optionnelles et, 191 
Melees quotidiennes, 364 
Melees quotidiennes, 95,364,535 
Menace(s), 397 
definition, 724 
strategies de, 442-443 

Mesure. l/o/VMetriques; Mesures de controle de la qualite; 
Metriques qualite 
Mesure, unites de, 182,238 
Mesure de performance, regies de, 239 
Mesures de controle de la qualite 
comme donnees d’entree, 124,291 
comme donnees de sortie, 305 
definition, 718 

Mesures de performance des couts, 262 
Methode de Monte-Carlo, 213-214,399,433,436 
Methode de selection basee sur les qualifications, 473 
Methode des antecedents (PDM). 189-190 
definition, 714 

methode des chemins critiques et, 210 
types de liaison, 190 
Methode des formules fixes, 182,239 
Methode du budget fixe, 474 
Methode du chemin critique (CPM), 210-211,227,704 
Methode du moindre cout, 473 
Methodes de communication, 374-375,383,701 
elements et, 375 
Methodes de livraison, 476 
Methodes de prevision, 92, 220-221 
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Methodes et supports de communication, 375 
Methodologie, 2, 711 
Methodologies hybrides, 73 

Metriques. Voir aussi Mesures de controle de la qualite; 
Metriques qualite 
performance d’execution, 109 
plan de management des benefices et, 33 
reussite du projet et, 34-35 
Metriques qualite 

comme donnees d’entree, 291,300 
comme donnees de sortie, 287 
definition, 718 

Mind mapping, 144, 284, 521,711 
Mise(s) a jour 
definition, 725 

demande de changement pour, 96 
Mise en parallele, 191,215, 228, 706 
Mises a jour des listes des vendeurs prequalifies, 501 
Mode alternatif de resolution de conflits (ADR), 498 
Modele d'echeancier, 722 
Modele d'echeancier du projet 
analyse du diagramme de reseau et, 209 
cible, 217 

developpement, 182 
donnees de I’echeancier pour, 220 
maintenance, 182,208 

Modele d’information de construction (BIM), 463 
Modele de perimetre. Voir Schemas contextuels 
Modele logique de donnees, 284 
Modele SIPOC, 284, 285 
Modeles, 40, 724 

Modeles de communication, 371-373, 701 
communication interculturelle, 373 
exemple interactif, 371 

Modeles de communication emetteur/recepteur, 371,381 

Moral, 45, 338 

Motivation 

competences d’equipe et, 341 
comportements et, 60 
gestion des conflits et, 348 
leadership et, 65,309 
personnel et, 197 
scenarii d’utilisateurs et, 145 
MOU. Voir Protocoles d’accord 
MSA. Voir Accord-cadre de services 


N 

Navigating Complexity: A Practice Guide, 68 
Negociation, 341,357, 488, 527 
Negociation des approvisionnements, 488 
Networking, 386, 534,711 
Niveau d'effort (LoE), 300, 325, 450, 709 
Niveau d’exactitude, 182, 238 
Niveau d’exactitude, 238 
Niveau du processus, integration a, 67 
Nivellement. l/o/r Nivellement des ressources 
Nivellement des ressources, 207,211,212,719 
Nceud, 189,435, 711 
Non-conformite 
couts et, 245, 282, 283 
prevention de, 274 
problemes, 303 
travail, 284 

NPV. l/o/'rValeur actuelle nette 

0 

Objectif, 712 

OBS. Voir Organigramme fonctionnel 
«Observation au poste de travail,»145 
Observation et discussion, 145,527 
Obtenir les ressources, 328-335, 601-602 
definition, 698 
donnees d’entree, 330-331 
donnees de sortie, 333-335 
outils et techniques, 332-333 
vue d’ensemble, 328-330 
Obtention, 698 

OPA. 1/o/rActifs organisationnels (OPA) 

OPM. Voir Management de projet organisationnel 
Opportunity, 397, 712 
strategies de, 444 

Opportunity strategique/besoin commercial, 546 
Organes de regimentation, 550 
Organigramme des ressources (RBS) 
comme donnees d’entree, 101,198, 355 
comme donnees de sortie, 326,335, 358 
definition, 719 
exemple, 327 

representation des donnees et, 316 
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p 


Organigramme des risques (RBS) 
categories de risques et, 405 
definition, 720 
exemple, 406 

Organigramme des travaux du projet (WBS). Voir aussi 
Processus Creer le WBS 
approches pour, 159 
comme donnees de sortie, 161 
definition, 726 
exemples, 159-160 
identifiant du WBS, 186 
lot de planification et, 161 
plan de gestion des couts et, 239 
reference de base du perimetre, 242 
representation des donnees et, 316 
valeur planifiee et, 261 
Organigramme du projet. 319,716 
Organigramme fonctionnel (OBS), 316,712 
Organigrammes, 370 

Organigrammes du projet et descriptions de poste, 316-317 
diagrammes de type hierarchique et, 316 
diagrammes matriciels, 317 
formats de type texte, 317 
Organisation fonctionnelle, 707 
Organisation(s) matricielle, 710 
Organisation realisatrice, 39, 40, 271, 332. Voir aussi 
Vendeur(s) 

Organisation sponsor, 33, 723 
Orientation de I'influence, analyse des parties prenantes, 
513 

Outil de planification, 722 
Outils 

automatises, 73 
definition, 725 
evolutions, 463 

gestion de I'information, 103-104 
gestion des connaissances, 103 
maTtrise des changements, 118-119,700 
processus du management de projet et, 22 
visuel de management, 73 
Outils automatises, 73,118 
Outils electroniques de management de projet, 385 
Outils visuels de management, 73 


Parametres. l/o/r Caracteristiques du projet 
Parametres de risque, evaluation d’autre, 423-424 
Partage, opportunite et, 444 
Partage des risques, 444, 721 
Partie(s) prenante(s). Voir aussi Processus Identifier les 
parties prenantes; Processus Gestion de I’engagement 
des parties prenantes; Partie(s) prenante(s) du projet 
bonnes pratiques et, 2 
classification de, 514 

considerations relatives a I’adaptation, 365 

definition, 723 

externe, 550 

interne, 550 

non satisfait, 10 

principal, 34, 80,145, 298, 407, 454, 624 
reunions de projet et, 364 
reussite du projet et, 34 
revues de projet et, 364 
Partie(s) prenante(s) du projet, 550-551 
exemples de, 551 
externe, 550 
interne, 550 

Parties prenantes externes, 361,550 
Parties prenantes internes, 550 
Passage d'etape, 21,545 

PBO. Voir Organisations de projets fondes (PBO) 

PBP. Voir Temps de retour sur investissement 

PDCA. l/o/'rCycle Planifier-Derouler-Controler-Agir (PDCA) 
PDM. Voir aussi MeVnode des antecedents 
PDPC. Voir Process Decision Program Charts (PDPC) 
Perception du risque, 420 

Perimetre, 722. Voir aussi Contenu du produit; Perimetre 
du projet 

Perimetre du projet, 131. Voir aussi Processus MaTtriser 
le perimetre; Processus Definir le perimetre; Processus 
Verifier le perimetre 
definition, 717 

demandes de changement et, 115 
description, 154 
Perimetre du travail 

contrat a prix ferme et definitif (FFP) et, 471 
liste d’activites et, 185 
plan de gestion du perimetre et, 469,484 
WBS et, 157,161 
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Phase. l/o/'rPhase(s) du projet 
Phase(s) du projet 
definition, 20, 716 
groupes de processus et, 555 
noms de phase et, 20 
vue d’ensemble, 20-21 
Phases de chevauchement de projet, 19,547 
Phases de I'approvisionnement, 476 
Plan d’engagement des parties prenantes, 87,140,279,522 
comme donnees d’entree, 368,381,390,509,525,532 
comme donnees de sortie, 387,393,522, 529,535 
definition, 723 

Plan de contingence, 72,439,445, 448 
Plan de gestion de I’echeancier, 87, 181. Voir aussi 
Processus Elaborer I'echeancier 
comme donnees d’entree, 184, 188, 198, 207, 224, 
236,411 

comme donnees de sortie, 181-182, 229,447 
definition, 722 

Plan de gestion de I’equipe, 724 
Plan de gestion de la communication, 87,377 
approches et, 374 

comme donnees d’entree, 381, 390, 484, 509, 518, 
525,532 

comme donnees de sortie, 377,387,393,490,529,535 
definition, 701 

formes de communication et, 374 
Plan de gestion de la configuration, 88,116,169,701 
comme donnees d’entree, 484 
Plan de gestion de la qualite, 87,320. Voir aussi Processus 
Gerer la qualite; Processus Planifier la gestion de la 
qualite; Gestion de la qualite du projet 
comme donnees d’entree, 135, 241,314,411,469 
comme donnees de sortie, 286, 297,447, 490 
definition, 718 

Plan de gestion des approvisionnements, 87,125 
comme donnees d’entree, 330,484, 495 
comme donnees de sortie, 447,475,490, 500 
definition, 714 

Plan de gestion des benefices, 33,251,469,509,699 
Plan de gestion des changements, 88, 116, 169, 495, 
525,700 

Plan de gestion des couts, 87,238 
comme donnees d’entree, 241,250, 259,411 
comme donnees de sortie, 238, 269,447 
definition, 703 

Plan de gestion des couts. Voir Gestion des couts du projet 


Plan de gestion des effectifs. Voir Gestion des ressources 
du projet 

Plan de gestion des exigences, 87, 137, 140, 165, 169, 
279,719 

comme donnees d’entree, 411,484, 495 
comme donnees de sortie, 490 
Plan de gestion des ressources; 87,250,318,322 
comme donnees d’entree, 368, 381, 390, 411, 439, 
469,518,532 

comme donnees de sortie, 334,351,358,447, 535 
definition, 719 

Plan de gestion des risques, 87,405. Voir aussi Processus 
Planifier la gestion des risques 
comme donnees d’entree, 236, 279, 412, 430, 439, 
484,495,518,525 

comme donnees de sortie, 287,405-408, 490, 500 
definition, 721 
elements de, 405-408 
Plan de gestion du perimetre, 87,137 
comme donnees d’entree, 140,165,169,180,469,484 
comme donnees de sortie, 137,171 
definition, 722 

perimetre du travail et, 469,484 
Plan de gestion organisationnel, 125 
Plan de management du projet, 86-89, 403. Voir aussi 
Processus Elaborer le plan de management du projet 
comme donnees d’entree, 92,100,107,116,123,135, 
140,152,157,165,169,180,184,188,198, 207, 224, 
236,241-242, 250, 259,279,290,300, 314,322,330, 
339, 347, 354, 368,381,390,411,421,430,439,450, 
455, 469, 484, 495, 509, 518, 525, 532, 568, 572, 621 
comme donnees de sortie, 97,105,112,120,171,186, 
221,229,269, 287, 297, 306, 334,343, 351,358, 378, 
387, 393,447,457,490, 500, 515, 529, 535,564, 572, 
576, 581,584, 591,598, 599, 600, 602, 603,605, 606, 
607, 609, 611,616,617, 620, 622,623, 625,626, 628, 
629, 631,632 

composants et, 88,116,135,165,169, 279, 314, 368, 
411-412,564, 568, 569,570, 572,573, 574, 575, 577, 
578, 579, 580, 582,583, 584, 585, 586, 588, 589, 591, 
593, 594, 597, 599, 600, 601,603,604, 606, 607, 608, 
610, 615,617, 618, 619, 621,623,624, 626,627, 629, 
630,632, 634 
definition, 716 

plans de management subsidiaires, 87 
references de base, 87 
Plan de repli, 439, 445, 448, 706 


746 


Troisieme partie - Index 



Planification a la demande, 177 
Planification d'iteration, 215 
Planification de release agile, 215 
Planification des communications, 333. Voir auss i 
Processus Planifier la gestion des communications; 
Gestion des communications du projet 
Planification des ressources, 217,313,314 
Planification des tests et des inspections, 285 
Planification en vagues, 160,185, 721 
Planification strategique, 185. Voir aussi Strategie 
organ isationnelle 

Planifier la gestion des communications, 366-378 
donnees d’entree, 368-369 
donnees de sortie, 377-378 
outils et techniques, 369-376 
vue d’ensemble, 366-367 
Plans de management subsidiaires, 87,558 
Plans subsidiaires, 83,135, 316, 479, 489,499 
Plurality, 144, 714 
PM. Voir aussi Chef de projet 
PMB. Voir Reference de base de la performance 
PMBOK® Guide. Voir Guide du Corpus des connaissances 
en management de projet 
PMI Talent Triangle®, 56-57 
PMIS. l/o/'rSysteme d'information de gestion du projet 
PMO. Voir Bureau des projets 
Point a traiter, 709 
Politique 

approvisionnement, 471 
definition, 714 

processus, procedures et, 40-41,102 
Politique, competences en leadership et, 62-63 
Politique qualite, 718 

Politiques d’approvisionnement, formelles, 471 
Portail commun, 340 
Porte de phase 
definition, 713 
description de, 21 
Portefeuille(s) 
definition, 11,15,714 
gouvernance de, 44 

programmes, projets et, 11-13,543-544 
Portefeuille de projet, 11 
Postes a long delai de livraison, 464 
Pourcentage d’avancement, 712 


Practice Standard for Earned Value Management, 182 
Practice Standard for Earned Value Management - Second 
Edition, 239 

Practice Standard for Scheduling, 175,178,207, 214 
Practice Standard for Work Breakdown Structures - 
Second Edition, 161 
Pratique, 714 

Pratiques emergentes. l/o//'Emergentes, pratiques 

Precision, niveau de, 238 

Presentations, 381,384,534 

Presentations d’echeancier du projet, exemple, 219 

Presentations de projet, 385 

Prevision, 264 

Prevision(s). Voir aussi Previsions de I’echeancier 
cout, 113 
definition, 707 
EAC, 239, 264, 265 

Previsions de couts, 113, 269,430, 448 
Previsions de I’echeancier 
comme donnees d’entree, 108,431 
comme donnees de sortie, 113,228 
definition, 722 

Previsions EAC, 239, 264, 265 
Prime d’interessement, 708 
Principaux concepts 

gestion de I’echeancier du projet et, 175 
gestion de I’integration du projet et, 72 
gestion de la qualite du projet et, 273-275 
gestion des approvisionnements du projet et, 460-462 
gestion des communications du projet et, 360-363 
gestion des couts du projet et, 233 
gestion des parties prenantes du projet et, 504-505 
gestion des ressources du projet et, 309-310 
gestion des risques du projet et, 397-398 
gestion du perimetre du projet et, 131 
Prise de decision 
business case et, 31 
efficace, 349 

Prise de decision autocratique, 119,144 
Probability et impact des risques 
description, 407 
evaluation, 423 
matrice/grille de notation, 408 
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Procedure(s) 
approvisionnement, 471 
definition, 714 

processus, politiques et, 40-41 
Procedures de partage des informations, formelles, 102 
Processus, 714 

Processus Clore le projet ou la phase, 121-128,634-635 
definition, 701 
donnees d’entree, 124-126 
donnees de sortie, 127-128 
outils et techniques, 126-127 
vue d’ensemble, 121-123 

Processus Creer le WBS, 156-162, 570-571. Voir aussi 
Organigramme des travaux du projet (WBS) 
definition, 703 
donnees d'entree, 157 
donnees de sortie, 161-162 
outils et techniques, 158-161 
vue d’ensemble, 156-157 
Processus d’attribution de contrat, evolution, 463 
Processus de cloture. 1/o/rGroupe de processus de cloture 
Processus Definir le perimetre, 150-155, 569-570 
definition, 704 
donnees d’entree, 152 
donnees de sortie, 154-155 
outils et techniques, 153 
vue d’ensemble, 150-151 
Processus Definir les activites, 183-186,572 
definition, 704 
donnees d'entree, 184 
donnees de sortie, 185-186 
outils et techniques, 184-185 
vue d’ensemble, 183 

Processus Determiner le budget, 248-256,578-579 
definition, 704 
donnees d'entree, 250-251 
donnees de sortie, 254-256 
outils et techniques, 252-253 
vue d’ensemble, 248-249 
Processus Developper I’equipe, 336-344,602-603 
definition, 705 
donnees d’entree, 339-340 
donnees de sortie, 343-344 
outils et techniques, 340-342 
vue d’ensemble, 336-339 


Processus Diriger et gerer le travail du projet, 90-97, 
597-598 
definition, 705 
donnees d’entree, 92-94 
donnees de sortie, 95-97 
outils et techniques, 94-95 
vue d’ensemble, 90-92 

Processus Effectuer (’analyse qualitative des risques, 
419-427, 588-589 
definition, 712 
donnees d'entree, 421-422 
donnees de sortie, 427 
outils et techniques, 422-426 
vue d’ensemble, 419-421 

Processus Effectuer I’analyse quantitative des risques, 
428-436, 589-590 
definition, 713 
donnees d’entree, 430-431 
donnees de sortie, 436 
outils et techniques, 431-436 
vue d’ensemble, 428-429 

Processus Effectuer la gestion integree des changements, 
113-120,616-617 
definition, 712 
donnees d’entree, 116-117 
donnees de sortie, 120 
outils et techniques, 118-120 
vue d’ensemble, 113-115 

Processus Elaborer I’echeancier, 205-221,575-576 
definition, 705 
donnees d'entree, 207-209 
donnees de sortie, 217-221 
outils et techniques, 209-216 
vue d’ensemble, 205-207 

Processus Elaborer la charte du projet, 75-81,563 
definition, 705 
donnees d’entree, 77-79 
donnees de sortie, 81 
outils et techniques, 79-80 
vue d’ensemble, 75-77 

Processus Elaborer le plan de management du projet, 
82-89, 567 
definition, 705 
donnees d’entree, 83-84 
outils et techniques, 85-89 
plan de management du projet, 86-89 
vue d’ensemble, 82-83 
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Processus Estimer la duree des activites, 195-204, 
574-575 
definition, 706 
donnees d’entree, 198-199 
outils et techniques, 200-204 
vue d’ensemble, 195-197 
Processus Estimer les couts, 240-247, 577-578 
definition, 706 
donnees d’entree, 241-243 
donnees de sortie, 246-247 
outils et techniques, 243-246 
vue d’ensemble, 240-241 

Processus Estimer les ressources necessaires aux 
activites, 320-327, 582-583 
definition, 706 
donnees d'entree, 322-324 
donnees de sortie, 325-327 
outils et techniques, 324-325 
vue d’ensemble, 320-322 

Processus Executer les reponses aux risques, 449-452,607 
definition, 708 
donnees d’entree, 450 
donnees de sortie, 451-452 
outils et techniques, 451 
vue d’ensemble, 449-450 

Processus Gerer I'engagement des parties prenantes, 
523-529,610-611 
definition, 710 
donnees d’entree, 525-526 
donnees de sortie, 528-529 
outils et techniques, 526-528 
vue d’ensemble, 523-524 
Processus Gerer I'equipe, 345-351,604-605 
definition, 710 
donnees d'entree, 347-348 
donnees de sortie, 350-351 
outils et techniques, 348-350 
vue d’ensemble, 345-346 
Processus Gerer la qualite, 288-297,599-600 
definition, 710 
donnees d’entree, 290-291 
donnees de sortie, 296-297 
outils et techniques, 292-296 
vue d’ensemble, 288-290 


Processus Gerer les communications, 379-388, 605-606 
definition, 710 
donnees d’entree, 381-383 
donnees de sortie, 387-388 
outils et techniques, 383-386 
vue d’ensemble, 379-381 

Processus Gerer les communications, 388-393, 627-628 
definition, 711 
donnees d’entree, 390-391 
donnees de sortie, 392-393 
outils et techniques, 391-392 
vue d’ensemble, 388-389 

Processus Gerer les connaissances du projet, 98-105, 
598-599 
definition, 710 
donnees d'entree, 100-102 
donnees de sortie, 104-106 
outils et techniques, 102-104 
vue d’ensemble, 98-100 

Processus Identifier les parties prenantes, 507-515, 
563-564 
definition, 708 
donnees d’entree, 509-510 
donnees de sortie, 514-515 
vue d’ensemble, 507-508 
outils et techniques, 511-514 

Processus Identifier les risques, 409-418, 586-587 
definition, 708 
donnees d’entree, 411-413 
donnees de sortie, 417-418 
outils et techniques, 414-416 
vue d’ensemble, 409-411 

Processus iteratif, 205,209,411 

Processus Maitriser I’echeancier, 222-230,621-622 
approche agile et, 224 
donnees d'entree, 224-225 
donnees de sortie, 228-230 
outils et techniques, 226-228 
vue d’ensemble, 222-224 

Processus MaTtriser I’engagement des parties prenantes, 
530-536,631-632 
definition, 711 
donnees d’entree, 532-533 
donnees de sortie, 535-536 
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outils et techniques, 533-535 
vue d’ensemble, 530-531 

Processus MaTtriser la qualite, 298-306,624-625 
definition, 702 
donnees d’entree, 300-302 
donnees de sortie, 305-306 
outils et techniques, 302-305 
vue d’ensemble, 298-300 

Processus MaTtriser le perimetre, 167-171,619-620 
definition, 703 
donnees d'entree, 169-170 
donnees de sortie, 170-171 
outils et techniques, 170 
vue d’ensemble, 167-168 

Processus MaTtriser le travail du projet, 105-113,615-616 
definition, 711 
donnees d’entree, 107-110 
donnees de sortie, 112-113 
outils et techniques, 110-111 
vue d’ensemble, 105-107 

Processus MaTtriser les approvisionnements, 492-501, 
629-631 
definition, 702 
donnees d’entree, 495-497 
donnees de sortie, 499-501 
outils et techniques, 497-498 
vue d’ensemble, 492-494 

Processus MaTtriser les couts, 257-270, 622-623 
definition, 702 
donnees d’entree, 259-260 
donnees de sortie, 268-270 
outils et techniques, 260-268 
vue d’ensemble, 257-259 

Processus MaTtriser les ressources, 352-358,625-626 
definition, 702 
donnees d’entree, 354-355 
donnees de sortie, 357-358 
outils et techniques, 356-357 
vue d’ensemble, 352-354 

Processus MaTtriser les risques, 453-458, 628-629 
definition, 711 
donnees d’entree, 455-456 
donnees de sortie, 457-458 
outils et techniques, 456-457 
vue d’ensemble, 453-454 


Processus Organiser les activites en sequence, 187-194, 
573 

definition, 723 
donnees d’entree, 188-189 
donnees de sortie, 194 
outils et techniques, 189-193 
vue d’ensemble, 187-188 

Processus Planifier I'engagement des parties prenantes, 
516-522,594 
definition, 713 
donnees d’entree, 518-520 
donnees de sortie, 522 
outils et techniques, 520-522 
vue d’ensemble, 516-518 

Processus Planifier la gestion de I’echeancier, 179-182, 
571-572 
definition, 713 
donnees d’entree, 180 
donnees de sortie, 181-182 
outils et techniques, 181 
vue d’ensemble, 179 

Processus Planifier la gestion de la qualite, 277-287, 
580-581 
definition, 713 
donnees d'entree, 279-281 
donnees de sortie, 286-287 
outils et techniques, 281-286 
vue d’ensemble, 277-278 

Processus Planifier la gestion des approvisionnements, 
466-481,592-593 
definition, 713 
donnees d’entree, 468-472 
donnees de sortie, 475-481 
outils et techniques, 472-474 
vue d’ensemble, 466-468 

Processus Planifier la gestion des communications, 
584-585 
definition, 713 
donnees d’entree, 368-369 
donnees de sortie, 377-378 
outils et techniques, 369-376 
vue d’ensemble, 366-367 

Processus Planifier la gestion des couts, 235-239,577 
definition, 713 
donnees d'entree, 236-237 
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donnees de sortie, 238-239 
outils et techniques, 237-238 
vue d’ensemble, 235-236 

Processus Planifier la gestion des ressources, 312-320, 
581-582 
definition, 713 
donnees d’entree, 314-315 
donnees de sortie, 318-320 
outils et techniques, 315-318 
vue d’ensemble, 312-313 

Processus Planifier la gestion des risques, 401-408, 585 
definition, 713 
donnees d’entree, 402-403 
donnees de sortie, 405-408 
outils et techniques, 404 
vue d’ensemble, 401-402 

Processus Planifier la gestion du perimetre, 134-137, 
567-568 
definition, 713 
donnees d’entree, 135-136 
donnees de sortie, 137 
outils et techniques, 136 
vue d’ensemble, 134-135 

Processus Planifier les reponses aux risques, 437-448, 

590-592 
definition, 713 
donnees d’entree, 439-441 
donnees de sortie, 447-448 
outils et techniques, 441-446 
vue d’ensemble, 437-439 

Processus Proceder aux approvisionnements, 482-491, 

608-609 
definition, 701 
donnees d’entree, 484-486 
donnees de sortie, 488-491 
outils et techniques, 487-488 
vue d’ensemble, 482-483 

Processus Recueillir les exigences, 138-149, 568-569 
definition, 701 
donnees d’entree, 140-141 
donnees de sortie, 147-149 
outils et techniques, 142-147 
vue d’ensemble, 138-140 

Processus Valider le perimetre, 131,163-167,618-619 
definition, 725 


donnees d’entree, 165 
donnees de sortie, 166-167 
outils et techniques, 166 
vue d’ensemble, 163-164 
Produit(s) 
definition, 715 
final, 127 
projets et, 4 

Produit, service ou resultat final, 127 
Programme(s) 
definition, 11,715 
gouvernance de, 44 

portefeuilles, projets et, 11-13,543-544 
Project Manager Competency Development (PMCD) 
Framework, 56 
Projet(s), 4-9 

besoins en financement, 256 
complexe, 461 
definition, 4, 542,715 
initialisation de, 546 
limites, 562 
multiphase, 86 

portefeuilles, programmes et, 11-13,543-544 
Projet de haut niveau/description du produit, 81,135,140, 
152,279, 314,402 

Projets fondes sur des modeles de type waterfall, 299,400 
Projets multiphases, 86 
Proposition(s). Voir Propositions de vendeurs 
Propositions des fournisseurs 
comme donnees d’entree, 486 
definition, 722 

Protocoles d’accord (MOU), 78,461 
Prototypes, 147, 717 
PV. l/o/'rValeur planifiee 

Q 

QFD. Voir Quality Function Deployment 
Qualite. Voir aussi Processus Planifier la gestion de la 
qualite; Gestion de la qualite du projet 
classe et, 274 
definition, 718 

Quality function deployment, 145 
Questionnaires, 143,303, 511,718 
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R 

RACI. Voir Matrice Realisateur, Approbateur, Consulte et 
Informe (RACI) 

RAM. l/o/r Matrice des responsabilites 
Rapport(s). Voir aussi Rapport de qualite; Rapport sur les 
risques 

final, 127-128 
performance d’execution, 26 
projet, 123, 361,362, 388 

Rapport de qualite, 108,124,165, 296, 382, 495, 718 
Rapport final, 127-128 
Rapport sur les risques 

comme donnees d’entree, 93,116,125,291,382,431, 
440, 450, 455 

comme donnees de sortie, 418,427,448, 452,458 
definition, 721 

Rapports d’avancement, 175,478,489. Voir aussi Donnees 
de performance d’execution 
Rapports de projet, 123,361,362, 388 
Rapports sur la performance d’execution, 26 
comme donnees d’entree, 116,347, 382,456 
comme donnees de sortie, 
definition, 726 

RBS. Voir Organigramme des ressources; Organigramme 
des risques 

RCA. Voir Analyse des causes originelles 
Reclamation, 700 
Recompenses, 319, 341-342 
Reconciliation des limites de financement, 253,707 
Reconnaissance, 319,341-342 
Reference(s) de base, 87, 699. Voir aussi Reference de 
base des couts; Reference de base du perimetre 
Reference de base de I’echeancier, 87. Voir aussi 
Echeancier, reference de base 
comme donnees d’entree, 116,224, 412,430,495 
comme donnees de sortie, 171, 186, 217, 229, 297, 
351,358, 447,490, 500 
definition, 721 

Reference de base de I’echeancier. Voir Echeancier, 
reference de base 

Reference de base de la performance (PMB), 88,621,712 
comme donnees d’entree, 169,224, 259 
comme donnees de sortie, 171,229,269, 620 


Reference de base des couts 
comme donnees d’entree, 116,259,412,430,439,484 
comme donnees de sortie, 171, 186, 221, 229, 254- 
255, 269, 297, 334, 351,358, 447,490, 500 
definition, 703 

Reference de base du perimetre. Voir aussi Processus 
MaTtriser le perimetre 

comme donnees d’entree, 116, 165, 169, 184, 188, 
198, 207, 224, 242, 250, 279, 314, 322, 412, 430,469 
comme donnees de sortie, 161-162, 171, 287, 297, 
447,490 
definition, 722 
elements de, 242 
Registre des changements 

comme donnees d’entree, 92,124, 382,510,519,525 
comme donnees de sortie, 529 
definition, 700 

Registre des parties prenantes 
comme donnees d’entree, 141, 280, 314, 331, 368, 
382, 413, 421,440, 470, 485, 496, 519, 525, 532 
comme donnees de sortie, 155, 287, 335, 378, 514, 

387.393.480.491.501.529.536 
definition, 723 

Registre des retours d’experience 
comme donnees d’entree, 92,101,108,124,141,165, 
169,198, 208, 225,242, 291,300, 339, 347,354, 382, 
390, 412, 440,450, 455, 484, 495, 525, 532 
comme donnees de sortie, 97,104,113,167,171,204, 
221,230, 247, 270,287, 297, 306, 327, 335,344, 351, 
358, 387, 393,418,448, 452,458,480, 491,500, 529, 
536 

definition, 709* 
description de, 104 
Registre des risques, 97 

comme donnees d’entree, 93,125,152,199,208,242, 
250, 280, 291,314,323, 355,421,431,440,450, 455, 
470,485,496, 519,532 

comme donnees de sortie, 113, 221, 230, 247, 256, 
270, 287, 297, 306,320, 335, 358,387, 417,427, 448, 

452.458.480.491.501.515.536 
contenu de, 417 

definition, 721 

Registres de la base de connaissances de I’organisation, 95 
Regimentations, 718 
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Regies de base, equipe projet, 320,348,528,708 
Relation acheteur-vendeur, 461 
Relation d’anteriorite. Voiraussi Relation logique 
definition, 714 

dependances internes et, 192 
Relations avec les parties prenantes 
complexite de, 506 
technology et, 464 
Repertoire de I’equipe de projet, 717 
Reponses aux risques, 436. Voir aussi Processus Planifier 
les reponses aux risques 
Reprise, 10, 720 

Reseau(x), 711. Voir aussi Diagramme diagramme de 
reseau du projet 

communication a I'aide des medias sociaux et, 374 
Reserve, 719. Voiraussi Reserve pour imprevus 
Reserve pour alea, 202, 245, 254, 439, 443, 702. Voir 
aussi Analyse de la reserve 
Reserve pour aleas des couts, 246 
Reserve pour I’inflation, 241,246 
Reserves pour imprevus, 202, 248, 252, 254, 256, 265, 
405, 710 

Resolution de conflits. l/o/'r Gestion des conflits 
Resolution de problemes, 295, 356 
Responsabilite, 319,720 
Responsabilite du management, 275 
Responsables fonctionnel 
chef de projet et, 52,55,325 
competences et, 332 
Ressource(s) 
definition, 719 
disponibilite de, 178 
nombre de, 197 
propre au secteur, 311 
Resultat(s). Voiraussi Livrable(s) 
definition, 720 
final, 127 
projets et, 4 
Retard(s) 
ajustement, 228 
avances et, 192-193,214 
definition, 193, 709 
exemples de, 192 

Retour d'information, 384, 527,534 


Retour sur investissement (ROI), 15,473 
Retours d’experience, 208. Voir aussi Retrospectives 
considerations relatives a I'adaptation, 74 
definition, 709 
reunions, 305 

Retrospectives, 224, 276, 305, 535. Voir aussi Retours 
d’experience 

Reunions, 80,95,111,127,136,181,185, 238, 286, 318, 
325, 342, 404 
analyse des risques et, 426 
comite de maTtrise des changements et, 120 
controle de la qualite et, 305 
estimations de la duree d’une activite et, 203 
gestion de, 80, 86,381,386 
identification des risques et, 416 
lancement du projet, 86 
lie au projet, 364,376 
maTtrise des changements, 120 
plan de management du projet et, 86 
projet, 364 

retrospectives/retours d’experience, 305 
revue des demandes de changement approuvees, 305 
revue des risques, 457 
types de, 528 
Reunions de projet, 364 
Reunions virtuelles, 103,392 
Reunions virtuelles, 376,377 
Reussite 

facteurs, critiques, 31 
projet, mesure de, 34-35 
Reussite du projet 
defaut ou, 123, 504 
mesures de, 34-35 

plan de gestion des benefices et, 546-547 
Revues 

conception, 233 

demandes de changement approuvees, 305 
documentation, 705 
pair, 303 

performance, 227,303,356, 498,712 
produit, 165 
projet, 364 
risque, 721 

Revues de conception, 233 
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Revues de performance, 227,303, 356,498,712 

Revues de produit, 166 

Revues des risques, 721 

Revues structures, 166,224,303,498 

RFI. 1/o/rDemande d'information 

RFP. Voir Appel d’offre 

RFQ. 1/o/rDemande de devis 

Risque(s). Voir aussi Risques identifies; Processus 
Identifier les risques; Processus MaTtriser les risques; 
Opportunites; Gestion des risques du projet; Risque(s) 
du projet; Menace(s) 
cycle de vie du projet et, 549 
definition, 720 
negatif, 395, 397 
niveaux de, 397 
positif, 395, 397 
projet global, 712 
residuel, 719 
secondaires, 722 
Risque d’ambiguite, 398,399 
Risque(s) du projet 
individuel, 397 
global, 397, 445-446, 712 
liste par ordre de priorite de, 436 
Risque global du projet, 397,712 
strategies de, 445-446 
Risque individuel du projet, 397 
Risque residuel, 448, 719 
Risques identifies, 31,399 
Risques negatifs, 395,397 
Risques non identifies«inconnu-inconnu,»202 
Risques positifs, 395, 397 
Risques secondaires, 448,722 
Role(s) 

chef de projet et, 51 
definition, 721 
responsabilites et, 318 


Satisfaction du client, 275 
Scenarii d’utilisateurs, 145 

Scheduling, Practice Standard for, 175,178,207, 214 
Schemas contextuels, 146,702 


Seances Joint application design/development (JAD), 145 
Securite, 24,45,315 
analyse des parties prenantes et, 512 
Design for X et, 295 

documentation des exigences et, 470,480,485,491,495 
exigences de la solution et, 148 
facteurs environnementaux de I'organisation et, 78,84,117 
Sequencement, 188 

Sequencement des activites. Voir Processus Organiser les 
activites en sequence 
Service(s) 
final, 127 
projets et, 4 
Seuil, 724 
Seuil de risque 
convenu, 398,445 
definition, 403 
definition, 721 
mesurable, 398,407 
Seuils de maTtrise, 181,182, 239,269 
Shewhart, Walter A., 275 
Simulation, 213-214, 433-434, 723 
Simulation de Monte-Carlo, 214,711 
Situation, analyse de la, 31 
Six Sigma, 275 

SLA. Voir Accords de niveau de service 

SME. l/o/r ac/ss/ Experts specialises dans le domaine 

« Soft skills », 53, 357 

Soumissionnaire. l/o/rVendeur(s) 

Souplesse, risque et, 424 
Sous-traitants, 38,462 
SOW. Voir Enonce des travaux 
Specifications, 723 

Sphere d’influence, chef de projet, 52-56 
SPI. Voir Indice de performance des delais 
Sponsor, 29, 723 
Sponsor du projet, 29 

Standard for Portfolio Management, The, 3,33 
Standard for Program Management, The, 3,14,33 
Standard for Project Management, The, 2-3,28 
vue d’ensemble, 541 
Standards de qualite. l/o/'rStandard 
Storyboarding, 147 
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Strategie d'amelioration 
opportunite et, 444 
risque global du projet et, 446 
Strategie d’approvisionnement, 476,715 
Strategie d’exploitation 
opportunite et, 444 
risque global du projet et, 445 
Strategie de I’acceptation active/passive du risque, 443-446 
Strategie organisationnelle 
jugement a dire d’expert et, 79 
structure de portefeuille et, 12 
Strategies de reponse conditionnelles, 445,702 
Structure(s) organisationnelle, 42, 44. Voir aussi Bureau 
des projets 

caracteristiques du projet et, 47 
choix de, facteurs en, 46 
hierarchique, 45 
organisation fonctionnelle, 707 
organisations matricielles, 710 
relations hierarchiques et, 319,329 
types de, 45-47 
Styles de communication, 373 
Suivi de chaque action, 94,110 
Suivre, 711 

SV. Voir Ecart de delais 
Syndicat de travail/contrats. l/o/rContrats 
Systeme(s). l/o/'r Systemes de ^organisation 
Systeme d’information. Voir Systeme d’information de 
gestion du projet 

Systeme d’information de management du projet (PMIS), 
26, 95, 193, 216, 227, 246, 268, 325, 350, 357, 385, 
392,451,716 

Systeme de gestion de la qualite, 718 
Systeme de maitrise des changements, 700. Voir aussi 
Systeme de controle des modifications du contrat 
Systeme de maitrise des modifications du contrat, 702 
Systeme de management de projet, 391,716 
Systeme Kanban, 177 

Systemes de gestion de I’information, 708. Voir aussi 
Systeme d'information de gestion du projet 
Systemes de gestion de la configuration, 41,701 
Systemes de gestion des contrats, 110,470,486 
Systemes de I’organisation, 42-44 
cadres de gouvernance et, 43-44 
vue d’ensemble, 42-43 


T 

T&M. Voir Contrat en regie 
Taille du projet, 400 
Talent, 56-57 
Tampon. Voir Reserve 
Taux interne de rentabilite (IRR), 34, 473 
TCPI. Voir Indice de performance a terminaison du projet 
Technique(s) 
definition, 724 

gestion de I’information, 103-104 
gestion des connaissances, 103 
processus du management de projet et, 22 
Technique d’analyse des donnees, 111, 119, 126, 136, 
143, 153, 170, 181, 202, 213-214, 226, 238, 245, 
252,261,282-283, 292,303, 325,356, 404,415,423, 
433-436, 446,456, 473,487, 498, 512, 521,533, 704 
Technique de planification iterative, 185,721 
Technique du groupe nominal, 144-145, 712 
Techniques analytiques, 699 
Techniques d’analyse graphique, 227,263 
Techniques d’ecoute, 386,534. Voir aussi Ecoute active 
Techniques devaluation des propositions, 717 
Techniques d’optimisation des ressources, 211-212,227, 
719 

Techniques de collecte des donnees, 80, 85, 142-143, 
281-282,292,302-303,414,422,432,442,473,511, 
520, 704 

Techniques de compression de I’echeancier, 215 
Techniques de modelisation, 209, 431 
Techniques de prise de decision, 111,119,144,153,166, 
203, 246, 283, 293,446, 521,534, 704 
criteres de selection, 332 
directives et, 349 

Techniques de representation des donnees, 144, 284- 
285,293-294,304,315,316-317,376,392,425-426, 
512-513,521-522,534, 704 
Techniques de representation graphique, 705 
Technologie. Voir aussi Technology de communication; 
Courriel; Logiciels; Conference par Internet 
communication, 365 
disponibilite/fiabilite de, 370 
evolutions, 78,197 

relations avec les parties prenantes et, 464 
soutien, 178 


755 



Technology de communication, 365 
Technologies de communication, 340,370,383,506,701. 
I /oiraussi Courriel; Conference par Internet 
choix de, facteurs en, 370-371 
considerations relatives a I’adaptation, 506 
Temps de retour sur investissement (PBP), 34,473 
Tendance(s) 

analyse quantitative des risques et, 436 

gestion de I’echeancier du projet, 177 

gestion de I’integration du projet et, 73 

gestion de la qualite du projet et, 275 

gestion des approvisionnements du projet et, 463-464 

gestion des communications du projet et, 364 

gestion des couts du projet, 233 

gestion des parties prenantes du projet et, 505 

gestion des ressources du projet et, 310-311 

gestion des risques du projet et, 398-399 

gestion du perimetre du projet et, 132 

propre au secteur, 55 

Termes de references (TOR), 468,469,478 

Termes du Lexique PMI du management de projet, 3 

Theorie des contraintes (TOC), 310 

Theorie des organisations, 318 

Time-boxing, 182 

TOC. 1/o/rTheorie des contraintes 

Tolerances, 274,725 

TOR. l/o/'rTermes de references 

Transfert. l/o/'r Transfert des risques 

Transfert des risques, 443,445,721 

Travail de conformite, 284,289 

Types de paiements, contrat, 476 

Types de paiements contractuels, 476 

u 

Unanimite, 144, 725 
Unites de mesure, 182,238 


V 

VAC. Voir Ecart a terminaison 
Valeur. l/o/'r Valeur commerciale 
Valeur acquise (EV), 261,705 
Valeur actuelle nette (NPV), 34,473 
Valeur commerciale, 8,10,148 
definition, 7, 700 
transition des etats et, 6 

Valeur de I’impact, 426. Voir aussi Matrice de probabilite 
etd’impact 

Valeur monetaire attendue (EMV), 435 
Valeur planifiee (PV), 261,713 
Validation 
definition, 725 
maitrise et, 133 
Variation, 725 
Vendeurs selectionnes, 488 
Verification, 725 

Verification et audit d’un element de configuration, 118 

Videoconference, 340 

Vision du produit, 216 

VOC. Voir aussi Voice of the Customer 

Voice of the Customer (VOC), 145,726 

Vote, 111, 119,144,534 

W 

WBS. Voir Organigramme des travaux du projet 

Work Breakdown Structures, Practice Standard for - 

Second Edition, 161 

X 

X, Design for X (DfX), 295 
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